On Thu, Dec 22, 2011 at 12:12:39PM -0800, Sebastian Sylvan wrote: > On Thu, Dec 22, 2011 at 11:55 AM, Graydon Hoare <gray...@mozilla.com> 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.
Very, very much agreed with this. I don't think we want to expose the fact that the machine represents (-1 as u8) as 0xff because rust code mostly shouldn't care, and if it does care, it can write '0xffu8' or whatever. We should certainly still support suffixes, but I think inferring them would help. > 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 > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- elly
signature.asc
Description: Digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
