On 12-03-19 07:00 PM, Patrick Walton wrote:
> On 3/19/12 6:56 PM, Tim Chevalier wrote:
>> I don't think we have any plans to add implicit casts as implied by
>> your other 4 examples. It seems too complex -- if any of the variables
>> in your example were mutated after being initialized, the pass that
>> would insert these casts would get pretty complicated.
>
> Actually, I don't think Chris was suggesting having a pass that computes
> the possible set of values for each local. I think he was getting at
> more of a "must-be-wider-than" relation among numeric types. For
> example, you know that every u8 value can be losslessly converted to an
> i16 based on the types alone.
>
> Java has something similar.
Promoting unsigned values to wider values carries the risk of widening
to a width you didn't expect, meaning you have an operation in the
middle of an expression happen with fewer bits than where you were
expecting. Say "(x << 8 | x & 0xff)". What's the temporary width for
each expression node? Too subtle to guess. The existing rule is good
here: "all the operands contributing bits need to be of the same width".
Promoting signed values to wider ones risks unexpected sign extension,
which is riskier still. "let i = 0xff;" .. did you mean -1 there?
I believe the only place we're considering relaxing this is the
following case (when all these conditions hold):
- Unadorned integer literal.
- Precise integer type context that unifies with it.
- Literal does not change sign when interpreted as the inferred
integer literal.
Other cases remain errors (which you can disable by either turning off
via the lint flags or adding literal suffixes).
This means "let x : i8 = 0xff;" would be an error -- it changes sign --
but "let x : i16 = 0xff;" would be ok.
Beyond this, I think the widening rules or any form of in-expression
promotion in general is too hazardous. Literals are the pain point.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
