On Mon, Oct 22, 2012 at 10:05 AM, Patrick Walton <pwal...@mozilla.com> wrote: > On 10/22/12 9:08 AM, Graydon Hoare wrote: >>> >>> I suggest allowing char literals when matching on an integer (or when >>> otherwise comparing to an integer or when assigning to an integer >>> variable) as long as the Unicode code point of the character >>> represented by the character literal is not greater than the largest >>> integer representable by the integer type. >> >> >> Interesting possibility. As in: add char literals to the set of types to >> which integer-type inference applies? > > > Seems to me that might be confusing. "match c as char" seems clearer. Just > IMHO, of course. >
+1 on explicit "as char". -1 on char literals inferred as numeric types. Explicit seems less surprising, especially where the inference result is hard to determine from examining source. It's a minimal amount of boilerplate and more readable. I'm not hating on inference here, which is an excellent language feature, I just assume it is possible to write large confusing expressions that may be surprising in cases like this, where a reader may not realize some inference rules. Relatedly, where can I find the casting rules between characters and integer types? I imagine two steps: Translate a character to an arbitrary precision integer, then translate that "ideal" value into a specific type by wrap-around, or truncation, or compilation error. If that's accurate, how is the first step accomplished? Is the unicode codepoint used, or is it ascii, or something else? If wrap around is used, does this mean casting different unicode characters (whose codepoints differ by 256) to u8 will yield the same u8 value? Can I cast the same character literal to u8 and i8 to get different semantic values (with the same bit-wise representation, assuming 2's complement)? I didn't notice where this is specified in the 0.4 manual. The only bit about casting I found says integer types can be cast between each other and pointers can be cast in various ways. Are characters considered integer types? Is there more specific documentation? If not, and if someone points me at the relevant source, I could take a crack at a documentation patch. I'm on the "purist / idealist" side of the fence in considering characters to be non-numbers, but I recognize that especially for a systems-compatible language, some C-like looseness in character types might be very practical. OTOH, I'd argue there's also a rich and ancient history of bugs, security problems, and usability problems around confusing characters and integers. Perhaps that is mostly around confusing "character" with C's i8 equivalent "char", though. > Patrick > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev Nathan _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
