Discussion: Inline type constraints

[alrz]

Inline type constraints

Proposal: dotnet/roslyn#7671

With numerous type parameters, type constraints require duplicating every type parameter to the point that it's somehow confusing,

internal abstract class AbstractUseCoalesceExpressionForNullableDiagnosticAnalyzer<
  TSyntaxKind,
  TExpressionSyntax,
  TConditionalExpressionSyntax,
  TBinaryExpressionSyntax,
  TMemberAccessExpression,
  TPrefixUnaryExpressinSyntax> : AbstractCodeStyleDiagnosticAnalyzer
  where TSyntaxKind : struct
  where TExpressionSyntax : SyntaxNode
  where TConditionalExpressionSyntax : TExpressionSyntax
  where TBinaryExpressionSyntax : TExpressionSyntax
  where TMemberAccessExpression : TExpressionSyntax
  where TPrefixUnaryExpressinSyntax : TExpressinSyntax

Inlining type parameters could significantly reduce noise around the type declaration,

internal abstract class AbstractUseCoalesceExpressionForNullableDiagnosticAnalyzer<
  TSyntaxKind : struct,
  TExpressionSyntax : SyntaxNode,
  TConditionalExpressionSyntax : TExpressionSyntax,
  TBinaryExpressionSyntax : TExpressionSyntax,
  TMemberAccessExpression : TExpressionSyntax,
  TPrefixUnaryExpressinSyntax : TExpressionSyntax> : AbstractCodeStyleDiagnosticAnalyzer

This syntax would bring type parameter constraints closer to their declaration,

void F<T, U : IEnumerable<T>>(U source) {}

Inlined type constraints can be mixed with default type parameters (#278), e.g.

class IEquitable<T : this = this> {}

Multiple type constraints can be inlined using "intersection types", using whatever syntax that they're going to use,

void F<T : Interface1 | Interface2>() {}

However, it might be actually preferable to only allow "simple" type constraints in this manner.

[chergey]

Support this. Would be quite handy.

[TonyValenti]

This is a great proposal. I would also love it if constraints were automatically inherited based on inference.

For example, this code is redundant:

Public class Super< T : Person> : Base<T> {

}

public class Base<T : Person> {

}

I should be able to say:

Public class Super<T> : Base<T> {

}

public class Base<T : Person> {

}

And have Super's T automatically pick up the T:Person constraint from Base. I've found it really annoying when I have a base class that has certain constraints and every time I work with a base class, I have to go change the constraints on every single derivative.

[alrz]

@TonyValenti https://ericlippert.com/2013/07/15/why-are-generic-constraints-not-inherited/

[julealgon]

I wonder why the original design was done this way in .NET using the where X : constraints approach. .NET generics came after Java already had it in place, and Java uses the less verbose approach similar to what is being suggested here, right?

Does anyone know why .NET decided on the verbose and duplication-prone strategy for defining constraints in the first place? I assume there must've been a strong reason at the time.

[HaloFour]

IIRC the belief was that embedding the constraints directly in the signature made it more difficult to see the signature, especially if there are multiple generic type parameters with different combinations of constraints and those constraints are also generic.

One big difference might be that in C# Foo<T> and Foo<T, U> are two completely different types, whereas that's not legal in Java at all.

F# does allow the constraints to be inlined, and also supports much more complicated forms of constraints.

[HaloFour]

@TonyValenti

I hate having to restate type constraints over and over again.

Whether or not generic constraints are inline isn't related to whether you have to "restate" them. Java forces this also:

public interface I { }
public class Foo<T extends I> { }
public class Bar<T extends I> extends Foo<T> { }

The reason being that the T in Foo<T> is completely unrelated from the T in Bar<T>, they just happen to have the same name. To use the T in Bar<T> as the generic type argument for Foo<T> it needs to be compatible with the constraints of T of Foo<T>, so you need to specify that constraint. Inheritance doesn't come into play here because even though Bar<T> might inherit from Foo<T>, there generic type parameters have no relationship to one another.

[TonyValenti]

@HaloFour - I misunderstood the statement, however, type constraints should be able to be inferred. For example, take the following code:

public class C2<T1, T2>
   where T1: class
   where T2: IEnumerable<T1> {
}

public class C3<TT1, TT2, TT3> : C2<TT1, TT2>
where TT3: ICollection<T1> {
}

public class C1<TTT1> : C3<TTT1, TTT1, TTT1> {

}

The constraints for T1 and T2 are known and defined on C2.

The constraints for TT1 and TT2 are knowable because of how they are used for C2.
TT1 unions all of T1's constraints and TT2 unions all of T2's constraints.

The constraints for TTT1 are also knowable because of how they are used for C3.
TTT1 unions all of TT1, TT2, and TT3's constraints.

[HaloFour]

@TonyValenti

I'd suggest opening a different discussion for that as it's unrelated to inline constraints. I disagree conceptually that inference flows in that direction, though. TTT1 is not related to TT1, TT2 or TT3. You're passing it as an argument to a different generic parameter. It's like saying that local variable inference should be based on the methods you just happen to pass that variable to.

[Joe4evr]

I hate having to restate type constraints over and over again.

My guess is that in the original design, someone said "we can ship faster if we don't inherit them and make you restate them every time". Once that got implemented various folks came afterwards looking for good reasons (like "it is more obvious") why you should have to restate them.

No, the real reason is that the onus is on you to prove that the constraints will still hold when the interactions become more and more complex, and any algorithm to automatically infer more is potentially unbounded. See https://ericlippert.com/2012/03/09/why-not-automatically-infer-constraints/