Implicit generic parameter declarations

[JimmyCushnie]

Hello. I've been a C# developer for 8 years, but this is my first time proposing a new language feature. Please let me know if I'm doing anything wrong; I couldn't find any guidelines on how to write productive proposals for this project.

---

Background

When writing code with a lot of generic parameters, you end up with a lot of repetitive boilerplate. For example:

abstract class ClassWithGenerics<TItems, TDataChunk, TItemsComparer>
    where TItemsComparer : IEqualityComparer<TItems>
{
    // ...
}

class ClassB<TClassWithGenerics, TItems, TDataChunk, TItemsComparer>
    where TClassWithGenerics : ClassWithGenerics<TItems, TDataChunk, TItemsComparer>
    where TItemsComparer : IEqualityComparer<TItems>
{
    // ...
}

static class ClassWithGenericsUtilities
{
    public static void DoSomethingWith<TClassWithGenerics, TItems, TDataChunk, TItemsComparer>(TClassWithGenerics classWithGenerics)
        where TClassWithGenerics : ClassWithGenerics<TItems, TDataChunk, TItemsComparer>
        where TItemsComparer : IEqualityComparer<TItems>
    {
        // ...
    }
}

The relevant base class, ClassWithGenerics, specifies three generic parameters, one of which has a type constraint. This is fine and makes sense.

However, every place we want to work with ClassWithGenerics, we have to repeat the generic parameters as well as the constraint. This is bad and annoying: it clutters the codebase and makes refactoring needlessly more difficult.

Proposal

To solve the described problem, I propose the following language feature:

• If a generic type constraint contains generic parameters, those generic parameters can be implicitly added to the class or method without requiring a separate declaration.
• If generic parameters are implicitly declared in this way, any type constraints from the original type are implicitly added and don't need to be re-declared.

With these rules, the above example becomes the following:

abstract class ClassWithGenerics<TItems, TDataChunk, TItemsComparer>
    where TItemsComparer : IEqualityComparer<TItems>
{
    // ...
}

class ClassB<TClassWithGenerics>
    where TClassWithGenerics : ClassWithGenerics<TItems, TDataChunk, TItemsComparer>
{
    // ...
}

static class ClassWithGenericsUtilities
{
    public static void DoSomethingWith<TClassWithGenerics>(TClassWithGenerics classWithGenerics)
        where TClassWithGenerics : ClassWithGenerics<TItems, TDataChunk, TItemsComparer>
    {
        // ...
    }
}

Much tidier, easier to read, and easier to maintain.

---

I'm currently working on a generics-heavy codebase and this would make my life much easier.

What do you think?

[HaloFour]

See also: #8710 #8967

[333fred]

Indeed, I'd say this is directly a duplicate of #8712.

[JimmyCushnie]

Indeed, I'd say this is directly a duplicate of #8712.

This is definitely not a duplicate of #8712.

[ufcpp]

So, this one? #339

[iam3yal]

@ufcpp I think that it's still different because with #339 you have to introduce another type that models the contract where I think what the OP proposes is that the type itself will be used to generate what the consumer would write to fulfill the contract on the generic class that you extend so I think the difference is with #339 you can model what TClassWithGenerics is whereas with this proposal you still don't know what TClassWithGenerics is but when you use it to extend another generic class then the compiler can generate what you would write yourself to extend it without passing all the parameters and such...

[iam3yal]

@JimmyCushnie I don't think the rules you laid out are enough to make things work or whether it's even possible to remove the parameters without additional syntax.. so you probably want something like this:

class ClassB<TClassWithGenerics...>
    where TClassWithGenerics : ClassWithGenerics<...> // or ClassWithGenerics<TClassWithGenerics...>
{
    // ...
}

This should be lowered by the compiler to the following form:

class ClassB<TClassWithGenerics, TItems, TDataChunk, TItemsComparer>
    where TClassWithGenerics : ClassWithGenerics<TItems, TDataChunk, TItemsComparer>
    where TItemsComparer : IEqualityComparer<TItems>
{
    // ...
}

I think that this makes things more clear and easier to explain so you might want to update the OP.

[AndersKehlet]

Yeah, the issue here is that the arity isn't apparent. Outright "lying" about the type's arity as in OP would be confusing, I think.

@JimmyCushnie if the issue is mostly about repeating constraints you may also be interested in F#'s nominal constraints. I agree that the way constraints infect other code can be annoying.

[iam3yal]

@AndersKehlet It is apparent though, when you consume the type it would be just like you explicitly wrote the type's arity yourself, nothing changes and they can add an IDE feature that when you hover over T... it shows you to what it expands.

[HaloFour]

Either way the disconnect is that the runtime type must have those generic type parameters explicitly declared as it's not possible for them to be "inferred" or "inherited" from other generic type parameters. You need language features to both expand out the generic type parameters into the actual real signature, as well as to infer them at the consumption site. The former, as described above, could easily be broken by something as innocuous as reordering constraints.

[AndersKehlet]

@iam3yal , I think the arity should be explicit in the type declaration. It's part of how you construct the type and having the compiler infer it would be like having inferred parameters to a function.

[siegfriedpammer]

• If a generic type constraint contains generic parameters, those generic parameters can be implicitly added to the class or method without requiring a separate declaration.

So, if I mistype the name (or the type gets removed in a library upgrade) of a type that is used as generic type argument in a constraint, the signatures/arity of types/methods are changed and I get unrelated/confusing errors at the use-sites of the type/method instead of its declaration? Sounds like a bad idea UX-wise...

[HaloFour]

Not to mention the inevitable collision of generic type parameter names. T, by itself, is very common. I think any proposal would have to provide some explicit declaration and mapping of the "inferred" generic type parameters.

IMO, it'd be less important to make the declarations less terse than the consumption. Apart from being safer it also applies to a larger multiple of cases as any given declaration is expected to be consumed more than once.