[Proposal]: Type parameter arrays in generic functions

[wes-sleeman]

TYPE PARAMETER ARRAYS IN GENERIC FUNCTIONS

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

C# has had parameter arrays in function calls and type parameters for a while now, but there is currently no way to pass a variable number of type parameters to a function. This proposal seeks to expand the params keyword to cover type parameters (only in functions for now) in addition to standard function parameters.

Motivation

Many applications in parsing and meta-programming require large- or undefined-scale passing of type information. Currently, there are only two approaches to doing this: passing an IEnumerable<Type> object as a normal parameter (which is counter-idiomatic and is opaque to compile-time checks), or nesting type parameter declarations (which is messy, difficult to implement, difficult to document, and all around confusing (reference System.Tuple<T1,T2,T3,T4,T5,T6,T7,TRest>). Implementing type param arrays would allow for significantly cleaner and more idiomatic function definitions in a variety of domains as well as allowing for some increased compile-time type-safety checking.

Detailed design

I propose we extend the params keyword to work in generic type specifiers. Specifically, populating the generic type parameter specified by the params keyword with an enumerable collection of generic type arguments such that indices of this collection can be used intuitively and resolved/checked at compile time like any other type parameters (e.g. TOthers[1] data = new(); for a generic type parameter specified with <…, params TOthers[]>). Refer to the below examples to get a feel for how it might be used. If extended to the class-level (beyond just the basics of this proposal), this could lead to significantly simplified definitions of classes such as System.Tuple<params TValues[]> or System.Func<TReturn, params TInputs[]> with all the maintainability and debugging benefits that come along with it.

Example usage with an array-like syntax to mimic the pre-existing function params format (pseudocode to demonstrate proposal, I'm aware that return new TReturn() { retval }; is invalid):

class Placeholder
{
    ///<summary>
    /// Key use-case: typechecking.
    /// Uses generic type params in conjunction with classic function params to improve compile-time type-checking.
    /// </summary>
    void MatchMulti<params TObjTypes[]>(params object values[])
    {
         for (int i = 0; i < values.Length; ++i)
             Assert.True(values[i] is TObjTypes[i]);
    }

     /// <summary>
     /// Nice-to-have: also accessible as IEnumerable{Type}.
     /// Returns new TReturn() { data } if TReturn implements all provided interfaces, else null.
     /// </summary>
    TReturn? Parse<TReturn, TInput, params TInterfaces[]>(TInput data) where TReturn : IEnumerable<TInput>, new()
    {
        Type[] implementedInterfaces = typeof(TReturn).GetInterfaces();
 
        if (TInterfaces.All(type => implementedInterfaces.Contains(type)))
            return new TReturn() { retval };
        else
            return default(TReturn?);
    }

    void CallOtherFunctions()
    {
        MatchMulti<string, int, float>("Test", 42, 3.14f);
        Parse<List<string>, string, IReadOnlyCollection<string>, IReadOnlyList<string>, IList>("Test data");
    }
}

Drawbacks

Depending on how it's implemented, produced code may not be compliant with the current ECMA-335; refactoring this construct into a chained format of <THead, TTail> where TTail can be either a type or another <THead2, TTail2>, etc before emitting the compiled assembly may remediate this. So long as the type-checking is implemented at the compiler level, the improved compile-time type-safety goal of this feature will be accomplished.

Unresolved questions

I'm not certain how Roslyn could be convinced to accept an array of type parameters and actually do the necessary checking. Implementing a dereference of an array of types shouldn't be too hard (I'm not familiar with Roslyn specifics, but it seems like it could be within a couple of extra conditions to dereference an array out of a symbol table in a typical compiler architecture), but some additional logic may need to be implemented that allows for type-checking these manoeuvres considering that this proposal doesn't require the indices to be compile-time constants.

[HaloFour]

See: dotnet/roslyn#5058
#4096

[HaloFour]

IMO the real question is how these variadic generic type parameters impact the members of the type. These types aren't particularly useful without some kind of runtime expansion of the type parameters into proper members which basically requires a form of runtime templating and the metadata to communicate to any compilers what members can be expected to exist and what their signature might be for any given combination of generic type arguments.

[wes-sleeman]

I appreciate the response. I saw those when researching before making this proposal, but noticed it had been closed when proposals were moved. I also felt that their design choices were a little more ambitious than I would consider a single-step feature, which is why I tried to keep this proposal more limited (i.e. functions only) and using a pre-existing keyword in a way that should feel natural to most comfortable C# programmers.

[wes-sleeman]

(Response to first comment): The idea here could be implemented at a basic level as just a (very convenient) bit of syntactic sugar over the nested, recursive, linked style of chaining type parameters that has already been successfully used in types like Tuple-8 (except this would be for functions). This wouldn't give the full functionality desired, but gives an idea of how the basics could be implemented without needing to influence the runtime.

[HaloFour]

This wouldn't give the full functionality desired, but gives an idea of how the basics could be implemented without needing to influence the runtime.

I'm not sure I understand this statement. Generics are entirely a runtime feature.

I guess my question would be what does what you've suggested above compile into? Where does the type checking come into play?

How does that simplify how types like Func<...> or Tuple<...> can be defined without runtime support?

[wes-sleeman]

Apologies, seems I wasn't able to clearly explain my thoughts. The implementation of wide-scale generic parameter arrays for things like classes wasn't a part of this proposal, merely a suggestion for ways the proposed feature could be extended in the future. For now, the suggested feature would have no changes to the runtime, but would simply be a syntactic nicety in function specifications which the compiler would swap out for a more standard approach (up to the implementer, my bet would be a linked-list type structure like what's used in the type definition for tuple-8) just like any of the other syntactic sugar that's already being stripped out and replaced at compile-time.