Type Parameter Inference from Constraints

[333fred]

Champion issue: #9453

Discussion area for the championed type inference issue. This is by no means the first discussion topic on this, linked below, but I wanted to make a fresh topic for the championed proposal.

• REQUEST: Pattern matching/better type inferencing with generics. roslyn#5023
• Better generic type inference based on type parameter constraints. roslyn#15166
• Improved type inference when generic argument has struct constraint #478
• Improved overload inference from generic type parameters/constraints #741
• Improve generic type parameters inference. #997
• improved auto generic type inference, proposal for backward compatibility. #1018
• Constraint type inference #6930
• Infer Type Argument of Generic Return Type by Examining Parameter Generic Types #7262
• Generic Chain Inference #8767
• Infer types from constraints roslyn#7850

[martin-steinhoefer]

In your proposal you mentioned a possible breaking change example (in Drawbacks section). I'm referring to that one.

When choosing extension methods during overload resolution the algorithm will select the one with the least generic arity - if I recall correctly. Shouldn't we do the very same here? That could remove that particular breaking. Do I miss something?

[333fred]

That's a tiebreaker, assuming all else is equal. It's not, as the generic has a better type (T) than the non-generic (object).

[jnm2]

Due to the lack of this inference from constraints, the extensions feature introduced CS9295 for when an extension member does not reference every type parameter introduced by the extension keyword. When the language adds the ability to infer type parameters from constraints, it would be really great to see the extensions feature remove this last roadblock as well.

Rationale for the following code: The GridRowMovedArgs type does not have a constraint where TRowArgs : IndexedValueArgs<TRow> because that would force it to have a second TRow type argument itself, and it's just not important in general to have that constraint. But when TRowArgs happens to be IndexedValueArgs<TRow> for any TRow, it would be nice to light up an int OldIndex convenience accessor next to int NewIndex.

public readonly record struct GridRowMovedArgs<TRowArgs>(TRowArgs Row, int NewIndex);

public static class GridRowMovedArgsExtensions
{
    extension<TRow, TRowArgs>(GridRowMovedArgs<TRowArgs> args)
        where TRowArgs : IndexedValueArgs<TRow>
    {
        // ❌ CS9295 The extended type 'GridRowMovedArgs<TRowArgs>' must reference all the type parameters declared by
        // the extension, but type parameter 'TRow' is not referenced.
        public int OldIndex => args.Row.Index;
    }
}