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.el...@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" <quans...@quanstro.net> wrote: > >> On Wed Nov 21 19:19:21 EST 2012, benave...@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 >> >>
