I agree with brucee here about the Go type names: I'd rather see uint64, int64, uint32, int32, etc.

usize doesn't bother me much.  New C programmers are often confused by size_t being unsigned (even experienced ones at times); this makes it clear.

On Wed, Nov 21, 2012 at 8:35 PM, Bruce Ellis <bruce.ellis@gmail.com> wrote:

i think that go's scalar types would work better. also usize is  a bit dicky.

brucee

On Nov 22, 2012 12:23 PM, "erik quanstrom" <quanstro@quanstro.net> wrote:

On Wed Nov 21 19:19:21 EST 2012, benavento@gmail.com wrote:
> hola,
>
> usize, really?
>
> any reason not use this opportunity to join the world and use inttypes.h or stdint.h format?

have you read the opengroup pubs?

        http://pubs.opengroup.org/onlinepubs/007904975/basedefs/stdint.h.html
        http://pubs.opengroup.org/onlinepubs/009604599/basedefs/inttypes.h.html

i don't see any advantage to using whatever types these guys are using.
when porting things from plan 9, it's good to have different type names.
the assumptions of various systems differ.  when porting things to plan 9,
you're likely going to be using ape anyway.

these headers are missing a type representing physical memory, and Rune.
no, i'm never going to consider using wchar_t instead.

yet they have types we do not want such as int_{least,fast} and int_max_t.
they seem to be a trap set by greybeards for unsuspecting young programmers.
one could hold this kind of thing up as a reason that c is an old and broken language.

and then there's the printf macros.  oh, joy.

i'm sure that others could back this up with more inteligent reasoning.  i'm just
prone to rant (had you noticed) when i see some of this stuff.

- erik