Interaction of user-defined and integral fallbacks with inference

[rkjnsn]

I prefer and would expect the “always use the user-defined default” rule. Like @Florob, I expect integer fallback to only be used as a last resort when there is absolutely no other type information (including defaults) available. If the second example were to compile, I would expect it to call foo<char> with “SYNCHRONOUS IDLE” (Unicode code point 22), with the literal statically verified to be a valid Unicode scalar value. Given that initializing a char with an integer literal is not supported, I would expect example two to be an error. I would would find it resolving to calling foo<i32> both counter intuitive and confusing.

[nrc]

I was a big fan of he DWIM approach, but the BigInt literal thing might sway me. However, I would like to understand why it is a problem. I imagine the tricky case is where the default is BigInt and the value is an integer literal. The question is then should we infer i32 or BigInt, and we would like to get the answer BigInt; the problem being that IntVar<_> and BigInt don’t unify, so we would end up using the integer fallback. Is this the problem?

I’m not sure how we plan to implement more liberal integer literals. But lets assume there is a trait with a lang item, wherever we have an integer literal we need to know what types it might be at the moment this is u8, i64, etc. In the future, we also include any types in scope which implement the lang item trait, so now the list is u8, i64, …, BigInt (or whatever). So now we try the DWIM procedure: 1st check if there is a type (there isn’t), then check if the default works (which it does because the default type unifies with one of the literal types), finally we would use the integer fallback, but we don’t have to in this case.

I believe we’d have to do the trait lookup in any case to type the integer literal, so it doesn’t seem any more complex to use DWIM with or without more liberal integer literals.

TBH, I think always using the default is also totally acceptable though, so I won’t object to option 1.

[aturon]

Thanks for the writeup; it’s a tough one.

Given the widely varying intuitions people seem to have, I’m with a few others who’ve voted for option #2: make such ambiguity an error for now, until we have more experience with defaults influencing inference in general.

[nikomatsakis]

Here $0 gets unified with Option<$1>, and then the whole thing later gets unified with Option<()>, which succeeds.

Can you elaborate on what you are trying to show me via this example? Is it simply this point:

We take advantage of IntVar not unifying with non-integers basically every time we conditionally unify - most importantly, trait and method lookup.

Yes, I am aware of this. What I am not sure of is the practical impact. That is, how often does it happen that we have e.g. an impl on a struct and on i32 (but no other type), such that we are able to unify the integer literal with i32 but ignore the struct. It’d be interesting to run some experiments on this and see what patterns break. (That could inform the decision here, as well.)

[nikomatsakis]

I believe we’d have to do the trait lookup in any case to type the integer literal, so it doesn’t seem any more complex to use DWIM with or without more liberal integer literals.

I think your summary was roughly accurate, yes. And yes, we have to do a trait lookup no matter what – but the way that fallback works is that we first resolve all outstanding trait references as best we can, then we do fallback, then repeat the process. I feel uncomfortable about fallback and type inference as it is; injecting further trait lookups into the process seems to me to be over the top. Imagine for example if the types may involve other variables that are potentially being inferred:

fn foo<T=u32,U=SomeType<T>>(...)

Now support that neither T nor U are constrained, so we are weighing fallbacks to u32 and SomeType<$T> (where $T is the type variable we created to represent T). I guess we can apply our usual procedure of testing whether a trait match could possibly succeed to decide whether SomeType<$T> might be an integral type, but you can see the confusion.

Of course similar situations can arise even today:

fn foo<T=u64,U=T>(x: &[T], y: U) { }
fn main() { foo(&[], 44); }

Here there are four type variables, let’s call them $T, $U, $22, and $44. $U is unified with $44. In order to detect ambiguous cases, we do not apply fallbacks in any particular order but rather consider all cases simultaneously. So we could have to examine the fallback for $U and we would find that it is $T (which is ununified). We don’t yet know what $T will become, so it’s tricky to know whether to apply the fallback. (In this case, since $T will ultimately become u64, we probably should, but it could as well be char). I think though this is not irreconcilable: we can presumably trace $T to its fallback(s) (or, if it is unified, to the type it is unified with) and try to reach a decision that way. Just complicated.

[nikomatsakis]

Given the widely varying intuitions people seem to have, I’m with a few others who’ve voted for option #2: make such ambiguity an error for now, until we have more experience with defaults influencing inference in general.

It is certainly the conservative choice.

[nikomatsakis]

@Gankro, can you elaborate a bit more on how you had hoped to use defaults to improve ergonomics?

[Gankro]

@nikomatsakis Oh sorry, missed this message!

Specifically the std lib currently has some curiously hardcoded type parameters just so simple things will “just work”. In particular, HashMap::new hardcodes SipHash. With default types we could replace these hardcodes in favour of just a default on HashMap and it should Just Work.

This completely avoids the question at hand though, since defaulting random integers for the std APIs would be Dumb for the most part.

Although in the future you could imagine adding a default param for the size of the hash, which would indeed default to u64.

[Gankro]

Actually BitVec and BitSet (now external crates) do something similar to HashMap but with the size of the backing blocks. Right now they hardcode u32 for almost everything to keep everyone Just Working from std. However in this case i32 isn’t an applicable choice (relevant trait only impl’d for unsigned types).

[iopq]

I’ve always expected that Rust would go in the “flexible literal” direction, because it’s the right thing to do. If the compiler can choose the correct size for you in some cases, that’s a huge benefit to prototyping. As it is now, even a medium size codebase is hard to refactor because all the types are concrete.

This can be extended further - strings can just be written in quotes like "Hello World" and the type system figures out if you want a String or &str or a Rope or what have you.

[Thiez]

I always considered the default integer fallback to be a last-resort kind of thing. As such I would expect the user-defined fallback to always take priority over the i32 fallback, because if I, as a user, really wanted a i32, I would have used the suffix. This means in the first example I would expect u64, and in the second I would expect i32. I pick the DWIM option. My second choice would be the ‘user-defined default always’ option.

[steveklabnik]

strings can just be written in quotes like “Hello World” and the type system figures out if you want a String or &str or a Rope or what have you.

While this would be nice for prototyping, Rust isn’t really shooting for being a prototyping language. We really try to make costs explicit, and all of these options have very different costs.

[iopq]

You can’t just prototype a Rust project in Ruby, what else are you going to prototype a Rust project in? A scripting language with an ownership system?

[steveklabnik]

You can’t just prototype a Rust project in Ruby

Why not?

[iopq]

That’s like prototyping a Rust project by putting everything inside an Rc

it actually doesn’t work because you’ll have to think about ownership eventually

[llogiq]

You may be thinking of productyping – that’s a weird bastard of prototyping and building a product. The end result usually fails both as a prototype and product (though there have been rare exceptions to this rule).

With prototyping you don’t want to think about ownership. Or lifetimes. Or types. Or anything that doesn’t directly relate to the thing that you want to prototype.

[iopq]

Let’s say I want to prototype a convolutional neural net library written in Rust. There’s already C++ implementations. How does Ruby help me?

[llogiq]

You don’t need to prototype if there are already implementations. In that case you can choose one and port.

[iopq]

Not really, because the C++ implementation will have classes, so you need to organize your Rust implementation differently and probably more Rusty instead of just emulating classes.

Because of this, you may not know the concrete types you’re using in your Rust implementation (that, and because you can’t use the C++ libraries), but you shouldn’t have to worry about what type you’re using until it becomes a bottleneck.

[notriddle]

The architecture of a prototype isn’t supposed to inform the architecture of the final product. The only purpose of a prototype is to show that the product can be built at all, and to figure out what the user requirements are. If you’re worried about implementation details, you’re not prototyping.