Default type parameter fallback revisited

[leodasvacas]

Thanks @nikomatsakis for early feedback! Tracking issue of the previous RFC rust-lang/rust#27336.

Rendered

[kennytm]

postoned ↦ postponed

[kennytm]

Do you mean y: Option<U> here?

[Centril]

I've only done a quick initial reading, but it seems compatible with RFC #2176 (partial turbofish).
If a function definition site has N type parameters and a function application site has M type arguments in turbofish, then before type inference, N - M amount of , _ will be inserted mechanically at the turbofish site. Type inference and any defaults are handled from there on.

[leodasvacas]

@Centril Yes this is intended to be compatible with that RFC, see this paragaph:

The behaviour of partially supplied parameter lists is as per RFC 213, omited parameters that have a default are inferred as if filled in with _.

[Centril]

@leodasvacas Wonderful! Then they don't need to block each other. Might I suggest adding a reference to #2176 in the relevant paragraph? For the roll-out plan, I suggest implementing #2176 first since it's a rather simple change and is a step on the way to this RFC.

[nikomatsakis]

cc @eddyb

[leodasvacas]

@petrochenkov Noticed your confused emoji reaction, would you like to expand on that?

[Ericson2314]

The reference explanation is still somewhat guide-y and missing some precision. I'm having a hard time understanding how the concerns from before about multiple defaults are mitigated, for example.

+1 on the basic idea/goals though.

[petrochenkov]

@leodasvacas
I have same concerns as @Ericson2314 basically.

[leodasvacas]

@Ericson2314 @petrochenkov The algorithm for applying fallback remains the one specified in RFC 213 modulo some considerations that I've added to this RFC. This RFC accepts that the algorithm fails on conflicting fallbacks and tries to mitigate that by documenting the practical implications to API evolution and proposing default elision, but there is no mitigation in the algorithm itself.

[aturon]

Note that @Centril, @leodasvacas and some others are now taking up discussion related to default type parameters on functions, turbofish, and more -- hopefully resulting in a new RFC. As such, I'm going to close this one for the time being.