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.
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
