Discussion: default type parameters

[alrz]

default type parameters

Proposal: dotnet/roslyn#6248

class X<TService = DefaultService> {}

Since types with identical names can be defined with different arities, it might be easier to require the diamond syntax (or missing type arguments) to disambiguate type arities. But not requiring it would provide source-compat such that you can add a type parameter with a default value, without changing use sites.

class Y : X {} // X<DefaultService>

One possible restriction to simplify binding rules is to disallow identical type names where there exists a type with default type parameters.

//ERROR
class X {}
class X<T = C> {}

However, even with this restriction there can be ambiguous type names, in those cases we prefer the non-generic type.

namespace N0 { class X {} }
namespace N1 { class X<T = C> {} }
namespace N2 {
    using N0;
    using N1;
    class C : X {} // N0.X
}

If we want to select the default parameter we can use X<> syntax or named type arguments.

We can also disallow leading default type parameters just like method default parameters,

class X<T = C, U> {} // ERROR

this as default type parameter

In some cases it's useful to define a default type parameter of the inheriting type (if any).

interface IEquitable<T = this> {}

class X : IEquitable {} // IEquitable<X>

It is also useful with shapes when we want the "self" type that is implementing the shape,

shape SGroup<T = this> {
    static T operator +(T t1, T t2);
    static T Zero { get; }
}

implement SGroup for int { // SGroup<int>
  // ...
}

It'd be nice to also constrain such types to the inheriting type, in case that it's explicitly specified. (#169)

interface IEquitable<T = this> where T : this {}

class X : IEquitable<Y> {} // ERROR

But this would be a C#-only restriction as CLR does not support such constraints. Note that this constraint only applies to the derived types so it might be preferable to restrict it to interfaces and abstract classes.

PS: One approach to resolve types is to do something like "overload resolution" on type arguments on top of #280, that would also cover some of #281 examples.

[TonyValenti]

Take a look at my comment on this since I get around Default type Parameters. Making something like this automatic in C# would be really nice:

#266 (comment)

[Joe4evr]

There's not a lot of details, so let me list some points to help spec this out. Correct me if anything doesn't sound right. For Default Type Parameters (DTPs):

Given a type declaration class X<T = C>:

1. Can be used on any type declaration [class, struct, interface] (Question: delegate? I'm thinking "Why not?", but I don't know if there happens to be anything funky about how they work.)
2. Lowers into the constraint where T : C, so the same rules as that constraint apply
3. Additionally, C is not allowed to be abstract or an interface (Unlike having the constraint normally.)
4. No additional constraints are allowed to be placed on T (EDIT: T : new() can be allowed, though I can't speak for its usefulness.)
5. Implementation would be done by applying an attribute on the generic parameter (Exact same reasoning as the nullable reference types proposal: older compilers will simply ignore the attribute.)

//in the end, the declaration would be the equivalent of this:
class X<[DefaultGenericArgument(typeof(C))] T> //attribute name is only for demonstration
    where T : C

6. When used by a compatible compiler, given the statement var x = new X<>();, the type specified in the [DefaultGenericArgument] attribute will be inferred to be put in the type argument list. (The variable is statically typed as X<C>.)
7. The <> of the type argument list may be omitted if there is no other type with the same name and a lesser generic arity in scope. (I'm thinking this should only apply in a local context. When as a field/property or being inherited class Y : X<>, the generic arity should be explicitly stated, but can otherwise be left blank.)

As far as I can tell, this is entirely syntactic sugar. Points 3 and 4 could potentially be subverted by IL rewriting, but if someone did that they would only shoot themselves in the foot and shouldn't be using a DTP in the first place.

Question: What would be the interaction of a DTP relying on other type parameters? I have the following type (which is pretty convoluted, but it works the way it should):

//not the actual type names
public class Foo<TBar, TBaz, TQux>
    where TBar : Bar<TBaz, TQux>
    where TBaz : Baz<TQux> //this one is abstract
    where TQux : Qux

Could DTPs be used here without needing to re-order the type parameters?

public class Foo<TBar = Bar<TBaz, TQux>, TBaz, TQux = Qux>
    where TBaz : Baz<TQux>

Or would TBar have to be moved to the end before it could use the TBaz and TQux tokens? (Not the end of the world.)

[Joe4evr]

For DTP keyword this:

Given a type declaration interface IX<T = this>:

1. Can only be used on abstract classes and interfaces
2. Lowers into the recursive constraint where T : IX<T>
3. Can have additional constraints placed on T
4. Implementation again, is an attribute

interface IX<[MustBeImplementingType] T> //again, attribute name is only demonstration
    where T : IX<T>

5. When used by a compatible compiler, given the declaration class X : IX<> the type of the implementing type will be inferred to be put in the type argument list. If additional constraints are specified, the implementing type will be checked to see if it abides. It should be an error to specify anything other than the implementing type in the type argument list at the position where type parameter is marked with the [MustBeImplementingType] attribute.
6. The <> of the type argument list may not be omitted (Consistency with point 7 above.)

As noted in the OP, point 5 cannot be enforced at runtime. Older compilers would also be able to put in any type as long as additional constraints match (if any), whereas with a DTP they would only require you to specify the appropriate type parameters explicitly and is not a behavioral change. The lowered constraint can alleviate some of this, but still wouldn't prevent the following:

public class A : IX<A>
{
}

//by using an older compiler or IL rewriting, this is still legal:
public class B : IX<A>
{
}

Question: Should it be a warning/error if more than one type parameter is marked with = this? I'm leaning towards "Yes", which at least keeps the door open to relaxing it down the line.
Combining with in/out on an interface? I can't see it having any use, probably "No" until further insight is had.

Overall, I'm personally not too thrilled about = this versus regular DTPs, but that's just me.