How about inferring the type of unadorned literals only, and allow an "i" suffix to force regular int interpretation? That way the programmer is free to make the judgment call of readability of code vs. clarity of intent herself.
We could also potentially investigate making the machine integer types have shorter suffixes. There are plenty of letters to go around. Patrick ----- Original Message ----- From: "Graydon Hoare" <[email protected]> To: [email protected] Sent: Thursday, December 22, 2011 2:55:11 PM Subject: Re: [rust-dev] Fwd: minor things that annoy you about Rust? I'm curious how many of the people upset at the literal suffixes know the number-literal syntax permits inserting underscores, so you can write this as (say): 0x_00ab_cdef_i32 Which is how I tend to write any suffixed literal that's not a very simple one (eg. 0u or such). The fact is that "being in range" is a fair bit heuristic and the more you guess the more likely you are to burn the user. 0xff means -1 as a signed octet and 255 as either an unsigned octet *or* a signed integer. Unless I sign-extend, which I have to decide whether or not I'm going to do when reading "0xff". Personally I still find the literal suffixes quite comforting and preferable to their absence in C, specifically because I have so much more mental work to do in C to guess whether-or-when I'm going to be accidentally truncating / wrapping / sign-extending etc. due to a conversion from the literal-I-said to the number-it-decided-to-use. I'm really only keen on discussing an alternative that doesn't reintroduce the C nightmare of "guess which boundary condition of 2s complement arithmetic you're going to burn yourself on today". -Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
