RFC: rustc: Allow any integral types on rhs of shift ops

[brson]

Fix for #1570. Making this an RFC since it's a language change.

The RHS of shift ops can be any integral type. This does nothing to address the various undefined situations that crop up with shifting.

[nikomatsakis]

This sounds great. I was a bit nervous about the effect on inference (we are no long unifying with an expected type) but I couldn't come up with any examples that wouldn't work.

[brson]

Yeah. It seems like there must be cases where we can't infer something, but if so the same issue exists with vector indexes.

[nikomatsakis]

it seems like, for any legit program, the shift amount will have been defined somewhere else and it will get its type from that location. the only problem would be if the type came from the shift operator itself, which only seems to occur in bogus programs like:

fn to_any_type<A>() -> A { fail; }
fn shift() {
    let s = to_any_type();
    3 >> s
}

conceivably this might have type checked before with s as type int. It certainly won't now... but do we really care?

[brson]

I think requiring an explicit type hint here is fine since it's the less common case by far. This change does add just a tiny bit more complexity to the type checker, and every bit counts. The person who actually tries to write that code is going to be confounded as to why it doesn't type check.

I think our inference algorithm is already complex to the point that you just have to believe the compiler when it says it can't infer the types, then add annotations until it compiles (like Scala I gather).

[nikomatsakis]

I think our inference algorithm is already complex to the point that you just have to believe the compiler when it says it can't infer the types, then add annotations until it compiles (like Scala I gather).

Agreed. I am fine with this.

Also, the annoyance of writing "foo >> 16u32" far outweights a theoretical concern about a theoretical program that could never successfully execute anyway. I guess a "real world" example might involve reinterpret case:

unsafe fn foo(x: *T) {
    let y = unsafe::reinterpret_cast::<int>(x);
    32 >> y
}

Here the type annotation is now required. This is sufficiently bizarre that I would hope you would annotate your type anyhow! :)

[graydon]

Yeah, this is ok. Requiring the LHS and RHS operands be "of the same type" makes sense when the operator is either:

• Calculating a result bit-by-bit from LHS bits and RHS bits (and/or/xor)
• A ring operator, subject to expression-reasoning by ring axioms (add,sub,mul,div,mod,comparisons)

The shifts don't really correspond to either. At best you can think of them as a funny notation for repeated application of mul2 and div2, except you still have sign extension to explain. They're pretty much a peculiarity of computers, and don't have any pretty algebraic axioms we're trying to preserve (associativity, commutativity, transitivity, etc. etc.)