Captured generic type arguments in constraints (associated type alias via using T)

[Zodt]

Captured generic type arguments in constraints (associated type alias via using T)

Summary

Introduce a way to “capture” generic type arguments appearing inside constraints and expose them as local type parameters without increasing the generic arity of the declaring method/type. The proposed syntax allows writing constraints like IValidator<using TRequest>, where using TRequest declares a captured type parameter TRequest that is inferred (bound) from the constrained type’s implementation. This removes redundant explicit type parameters that are only there to “pipe through” an associated type of another generic.

Motivation

Today, APIs frequently need to couple one type parameter to another via a constraint, e.g., where TValidator : IValidator<TRequest>. In most such cases, TRequest is not a degree of freedom that the caller conceptually chooses; instead, it is logically owned by TValidator and should be inferred from it. Requiring an explicit TRequest:

• Inflates the public arity and noise of the API.
• Forces developers to surface a parameter that is never chosen directly by the call site.
• Adds error surface (mismatches between TValidator and TRequest).
  The proposal removes TRequest from the public arity while keeping it strongly typed and available inside the declaration body.

Detailed design

New concept: captured type parameter

• A captured type parameter is introduced in a constraint by placing using Identifier in a type argument position of a constructed type.
• It is not part of the declaring method/type generic arity.
• It becomes in-scope inside the declaring member (and subsequent constraint clauses of the same declaration) and can be used as an ordinary type parameter in the body and in additional constraints.

Grammar sketch

• Extend type_argument with a new form:
  • type_argument ::= type | using identifier
• using identifier is only valid in type argument positions that syntactically appear within a type_parameter_constraints_clause.
• It is an error if identifier collides with an already declared type parameter name in the same declaration.

Binding and semantics

• In a constraint like where TValidator : IValidator<using TRequest>, the compiler searches the actual type substituted for TValidator for an implementation that makes it an IValidator<X> for some X. If such X exists and is unambiguous, bind TRequest := X.
• Captured parameters can carry additional constraints:
  • Example: where TValidator : IValidator<using TRequest> where TRequest : class
  • These are checked after binding (TRequest := X).
• Captured parameters participate in type checking within the declaring body as if they were declared type parameters. They do not participate in caller-supplied type argument lists nor in standard method type inference from call arguments.

Ambiguity rules

• If multiple distinct X satisfy the capture for the same using parameter (e.g., the type implements IValidator<Foo> and IValidator<Bar>), binding is ambiguous and the declaration is not applicable at the call site. The compiler should report a dedicated diagnostic (e.g., “ambiguous associated type binding for ‘TRequest’”).
• Ambiguities can be resolved by adding further constraints (e.g., where TRequest : FooBase) or by reverting to an explicit type parameter.

Variance

• Binding respects variance annotations of generic interfaces/base types. A unique best match must exist after considering variance; otherwise, ambiguity is reported.

Metadata and reflection

• Captured type parameters do not increase generic arity and are not represented as public type parameters in metadata.
• Inside the method body, usage sites (e.g., constructed types like SomeType<TRequest>) behave as if TRequest were a regular type parameter bound at use time, with a concrete type substituted upon successful binding.
• Debug info may surface the captured parameter name for better tooling experience.

Overload resolution

• A member with captured parameters participates in overload resolution as usual. Applicability includes successful binding of captured parameters during constraint satisfaction. Captured parameters are not inferred from call arguments and are not part of the generic argument lists considered by overload resolution.

Constraints visibility order

• Captures become available in constraints and in the body after their first syntactic introduction. Implementations may process where-clauses left-to-right to establish availability; alternatively, the language can specify that all constraints in the declaration form a single environment with intra-declaration capture order defined by textual occurrence.

Restrictions

• using identifier is only permitted in type argument positions that appear syntactically within constraints.
• It is not permitted in normal type argument positions outside constraints, in using-alias directives, attributes, nameof/typeof expressions, etc.
• A capture cannot refer to a not-yet-introduced captured parameter unless the implementation defines an order that makes it available; simplest rule: a capture is visible only after its first appearance.

Examples

Current (redundant explicit type parameter)

public static class ValidationExtensions
{
    public static TValidator CreateValidationFilter<TValidator, TRequest>()
        where TValidator : class, IValidator<TRequest>, new()
    {
        return new ValidationFilter<TRequest>(
            validator: new TValidator()
        );
    }
}

Proposed (captured associated type)

public static class ValidationExtensions
{
    public static TValidator CreateValidationFilter<TValidator>()
        where TValidator : class, IValidator<using TRequest>, new()
        where TRequest : class
    {
        return new ValidationFilter<TRequest>(
            validator: new TValidator()
        );
    }
}

Multiple captured associated types

public interface IMap<TSource, TDest> { /* ... */ }

public static class MappingExtensions
{
    public static TResult MapWith<TMapper, TResult>(this object source)
        where TMapper : IMap<using TSource, using TDest>, new()
        where TSource : class
        where TDest   : class, TResult
    {
        var mapper = new TMapper();
        return (TResult) MapInternal<TSource, TDest>(source, mapper);
    }

    private static object MapInternal<TS, TD>(object src, IMap<TS, TD> mapper)
        where TS : class
        where TD : class
        => /* ... */;
}

Ambiguity and disambiguation

public sealed class DualValidator : IValidator<Foo>, IValidator<Bar> { /* ... */ }

// Error: ambiguous associated type binding for 'TRequest' (Foo vs Bar).
public static void UseAmbiguous<TV>()
    where TV : IValidator<using TRequest>, new()
{
    // ...
}

// Disambiguate via an additional constraint:
public static void UseWithConstraint<TV>()
    where TV : IValidator<using TRequest>, new()
    where TRequest : FooBase
{
    // Now only one implementation matches.
}

Variance-aware capture

public interface IProducer<out T> { }
public interface IConsumer<in T> { }

public static class VarianceDemo
{
    public static void Produce<TP>(TP producer)
        where TP : IProducer<using TItem>
    {
        List<TItem> list = [];
        // ...
    }

    public static void Consume<TC>(TC consumer)
        where TC : IConsumer<using TArg>
    {
        Action<TArg> handler = _ => { };
        // ...
    }
}

Unresolved questions

• Exact visibility/ordering rules across multiple where-clauses: single environment or left-to-right staged?
• Precise metadata/debug info representation to aid tooling (names, bound concrete types in PDB).
• Interaction with nullable annotations (e.g., should captured parameters inherit nullability context from the captured position?).
• Interaction with default interface implementations and explicit interface implementations when multiple candidates exist.

Prior art

• “Associated types” in languages like Rust (traits) and Swift protocols solve a similar problem by tying a type member to a conforming type.
• C# today emulates this with extra generic parameters plus constraints, which this proposal streamlines.

Implementation notes

• Parser: allow using identifier tokens as a kind of type argument only inside constraints.
• Binder: during constraint satisfaction, attempt to match constructed forms containing using T to actual interface/base implementations; upon success, bind the captured parameter.
• Overload resolution: consider a candidate applicable only if all captured parameters bind unambiguously and subsequent constraints on them pass.
• Diagnostics: introduce specific error codes for (a) use of using outside constraints, (b) name collisions, (c) ambiguous capture, (d) capture not found.

Benefits

• Reduces API surface generic arity and improves readability.
• Avoids mismatches between “owner” and “associated” type parameters.
• Makes intent explicit and discoverable: the type is not chosen by the caller but derived from another type via constraints.

[333fred]

Duplicate of #8712. See discussion in #8712 and #8711.