Document Default Type Parameter Fallback

[jroesch]

Now that #26870 has landed we should document the behavior of the algorithm in the book. I would be happy to draft/review docs for this.

cc @steveklabnik

[steveklabnik]

a draft would be great

[initsecret]

I can help,
PS I'm not a pro with rust, neither am I pro with docs, But I can lend a hand
If you can give me a basic draft I think I can do it.

[comex]

The linked PR says:

This is almost certainly a breaking change due to interactions between default type parameters and the old fallback algorithm used for integral and floating point literals.

Can someone who understands the algorithm better than I come up with an example where this actually breaks (stable) code?

In particular, the RFC itself says it "gives defaulted type parameters precedence over integer/float literal fallback", but that doesn't seem to be the case - it has this example:

// Here the type of the integer literal 22 is inferred
// to `uint` because the default on `T` overrides the
// standard integer literal fallback.
fn foo<T=uint>(t: T) { ... }
foo(22)

but the equivalent on nightly:

#![feature(default_type_parameter_fallback)]
fn foo<T=u64>(t: T) { println!("{}", std::mem::size_of_val(&t)); }
fn main() { foo(22); }

outputs 4, i.e. the type was inferred to u32.

If this actually has the potential to be a silent, subtle breaking change once it's ungated, I'm sad...

[jroesch]

@comex @nikomatsakis and I talked for a while today and we realized that my reading of the RFC prefers integer and floating fallback due to a subtlety of type inference I missed, and he didn't catch when reviewing my PR. I am going to have a follow up patch in the next few days that fixes the above case.

[nikomatsakis]

@comex this certainly has the potential to cause subtle breakage. Once we patch up the code, I think before enabling the feature gate it behooves us to do a cycle where we identify those cases that will behave differently and issue warnings.

[comex]

In that case -

I suppose this RFC was mentioned explicitly in the language stability RFC... even so, someone who read the 1.0 announcement and other evangelism, but not the entire RFC, would be excused for thinking that in the statement -

breaking changes are largely out of scope (some minor caveats apply, such as compiler bugs)

- the caveats in question were actually minor, or that compiler bugs were actually a typical example of why breaking changes might be necessary, as opposed to the language landing two significant gratuitous breaks in two months. (This is worse than the previous one because it can silently change runtime behavior rather than just causing compile errors.) I have to wonder whether these are only teething problems in the language, which will be worked out in time, or potentially a sign of an ongoing culture of unseriousness when it comes to stability. :(

[and if this RFC has been known to be coming for so long before 1.0, why weren't default type parameters gated or something?]

[Gankra]

What's the status on this? Blocked on MIR?

[nikomatsakis]

On Wed, Dec 09, 2015 at 11:03:11AM -0800, Alexis Beingessner wrote:

What's the status on this? Blocked on MIR?

I'm supposed to be rebasing Jared's branch but haven't
gotten to it. That said, I'm rethinking the whole idea, see here:

rust-lang/rfcs#1196 (comment)

[jroesch]

@nikomatsakis My busy-ness due to having to completely solo TA undergrad OS is now over (sans final grading) I'm free again and looking to hack.

[Gankra]

🎊

[steveklabnik]

Given these questions, I'm just going to close this issue. Once we figure out what's going on, we can document it.