On Thu, Dec 22, 2011 at 11:55 AM, Graydon Hoare <[email protected]> wrote: > On 11-12-21 09:10 PM, Joe Groff wrote: > >> 1. I support being able to drop mandatory literal type specifiers on >> values that are within the range of their expected type >> >> Related: I'd like contributed source highlighting code for vim, >> emacs etc. to highlight all literal type specifiers >> (very long f32, f64 literal constants can be difficult to read >> otherwise, e.g. -XXXX.YYYYe-Zf32) >> >> >> Think also of hex literals (e.g. 0xabcdefi32). Syntax highlighting seems >> like a hack to get around syntax that just plain sucks. If you guys are >> open to changing the literal suffix syntax, the C tradition of magic >> letters may not be theoretically appealing but it would be much more >> ergonomic. > > > 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.
IMO literals shouldn't take into account the fact that the underlying bit representation may also have other interpretations. So 255 would mean 255, not -1, under any circumstances. The fact that -1 can be represented in the same way on the level of bits doesn't make 255 equivalent to -1 when you decide what types it's compatible with (in this signed integers of more than 8 bits, and unsigned integers of 8 bits or more, plus floats). If you want -1, you have to write -1, or do some kind of reinterpret_cast on 255 to a type where that bit patterns means -1. Same goes for hex. 0xff means 0xff, not -0x01. The fact that the literal->bits translation may not be injective doesn't mean that any two values that happen to have the same bit representation should be considered the same for the purposes of inferring type. With that in place, I don't think that leaving off suffixes would be an issue for literals that fit. Seb -- Sebastian Sylvan _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
