# C# Language Design Notes for Nov 25, 2019

## Agenda

1. Allow `T?` where `T` is a type parameter that's not constrained to be a value or reference type

# "Unconstrained" `T?`

In C# 8.0 we entertained the possibility of allowing `T?` on type parameters `T` that are unconstrained, or constrained only in a way that they can still be instantiated with both value and reference types.

The idea was to accurately express the type of `default(T)`. To this end, `T?` would end up being the same as `T`, except when `T` is instantiated with a nonnullable reference type `C`, in which case `T?` is `C?`. The reason is that for non-nullable reference types `C`, `default(C)` is still null, and hence of the type `C?`, not `C`.

`T?` would, for instance, allow the return type of methods like `FirstOrDefault()` to be better expressed:

``` c#
public T? FirstOrDefault<T>(this IEnumerable<T> src);
```

In the generic context where `T` is in scope, the meaning of `T?` would be "may be null, even when `T` is not nullable". The expression `default(T)` would no longer warn, but the type of it would be `T?`, and assigning `T?` to `T` *would* warn.

In the end we decided not to allow `T?` due to a couple of problems which we'll get back to below. Instead we addressed many of the scenarios with the addition of nullable attributes such as `[MaybeNull]`, which can be used to annotate e.g. the `FirstOrDefault()` method:

``` c#
public [return:MaybeNull] T FirstOrDefault<T>(this IEnumerable<T> src);
```

## Recent changes

Default values keep causing grief, and we've recently [(Nov 13)](https://github.com/dotnet/csharplang/blob/master/meetings/2019/LDM-2019-11-13.md#improved-analysis-of-maybenullt) decided on some changes to handle them:

1. Add a third null-state next to "not null" and "maybe null", which is "maybe null *even* when the type doesn't allow", and make that the null state of `default(T)` for an unconstrained type parameter `T`, as well as results of method calls etc. (such as `FirstOrDefault`) that were annotated with `[MaybeNull]`
2. Remove the "W warning" on assignment of such values to locals of type `T`, but instead subsequently track the new state *for* those locals, which may subsequently lead to warnings if used unsafely
3. Remove warnings when producing such values as a result (e.g. return value) that is itself annotated as `[MaybeNull]`

Put together, these three eliminate most of the friction around the use of `default(T)` and `[MaybeNull]`. However, they also get very close to the previously proposed semantics of allowing `T?` on unconstrained `T`. We could take this two ways:

1. Since we mostly succeeded in addressing the problem without `T?`, it further reduces the need for it.
2. This shows that "the type of `default(T)`" is an important concept that should be properly reified in the language instead of tricks with attributes.

## Taking another look at "unconstrained" `T?`

The main arguments in favor of a syntax for "the type of `default(T)`" even with the above changes are:

1. By adding "it" as a tracked null state, we're already half embracing it, but by leaving it inexpressible as a type we need to fall back on "tricks" to make use of it
2. `[MaybeNull]` doesn't help when "the type of `default(T)`" is needed in a constructed (array, generic, tuple, ...) type

The use of the syntax `T?` to mean "the type of `default(T)`" as two significant problems as well, which ultimately led us to not embrace it for C# 8.0:

1. Its meaning is different from the meaning of `T?` when `T` is constrained to be a value type.
2. Overrides cannot restate their constraint, and `T?` in those today always means the value type kind.

## Problem 1: `T?` and `T?` mean different things

The first problem is not technical, but one of perception and language regularity. Consider:

```
public T? M1<T>(T t) where T : struct;
public T? M2<T>(T t);

var i1 = M1(7); // i1 is int?
var i2 = M2(7); // i2 is int
```

The declaration of `M1` is legal today. Because `T` is constrained to a (nonnullable) value type, `T?` is known to be a nullable value type, and hence, when instantiated with `int`, the return type is `int?`.

The declaration of `M2` is what's proposed to allow. Because `T` is unconstrained, `T?` is "the type of `default(T)`". When instantiated with `int` the type of `default(int)` is `int`, so that is the return type.

In other words, for the same provided `T` these two methods have *different* return types, even though the only difference is that one has a constraint on `T` but the other does not.

The cognitive dissonance here was a major part of why we didn't embrace `T?` for unconstrained `T`.

## Problem 2: pseudo-"unconstraint" in overrides for disambiguation

In C# overrides of generic methods cannot re-specify constraints, but must inherit them from the original declaration. Before C# 8.0, when `T?` appeared in signatures of such overrides, it was always assumed to mean the nullable value type `Nullable<T>`, because what else could it mean?

In C# 8.0 `T?` acquired the possible second meaning of nullable reference type. In order to disambiguate the search for the original declaration, we reluctantly introduced the ability to specify "pseudo-constraints" on the overrides: When `T` was a type parameter constrained to be a reference type, you can now say so by adding `where T: class` to the declaration. If you want the default assumption of it being constrained to a value type to be made explicit, you can also optionally specify `where T: struct`.

These helper constraints are only there to help find the right declaring method up the inheritance chain (which may be overloaded). The *actual* constraint that's emitted into generated code is still the one that's inherited from the original declaration, once that one has been identified. Thus, only `class` and `struct` can be used as constraints on an override.

Now here comes a third `T?`, the defining characteristic of which is that it is *not* constrained to be either a reference or value type. To distinguish it from the other two in an override of a generic method, we would need a third "constraint" that is actually an *unconstraint* - that specifically says that it is *not* constrained!

## Solutions

We have two general approaches to address these problems (beyond the ever-present solution of giving up on the feature):

1. Live with problem 1, and try to explain things as best we can. Find a syntax to express the "unconstraint" of problem 2.
2. Use a different syntax than `T?` to express "the type of `default(T)`".

## Solution 1

A brain storm for solution 1 syntaxes yielded:

``` c#
override void M1<[Unconstrained]T,U>(T? x)           // a
override void M1<T,U>(T? x) where T: object?         // b
override void M1<T,U>(T? x) where T: unconstrained   // c
override void M1<T,U>(T? x) where T:                 // d
override void M1<T,U>(T? x) where T: ?               // e
override void M1<T,U>(T? x) where T: null            // f
override void M1<T,U>(T? x) where T: class|struct    // g
override void M1<T,U>(T? x) where T: class or struct // h
override void M1<T,U>(T? x) where T: cluct           // joke
```

Of these we have a vague preference for c, expressing explicitly that there is *not* a constraint, closely followed by b, which is the most general constraint one could state. None of the others resonated.

## Solution 2

A brain storm for solution 2 syntaxes yielded:

``` c#
void M1<T,U>(default(T) x) // X
void M1<T,U>(default<T> x) // Y
void M1<T,U>(T?? x)        // Z
```

Solutions X and Y try to be explicit about the type meaning "the type of `default(T)`", but run the risk of implying "the result *is* `default(T)`". Solution Z is mostly just the shortest `?`-like token we could think of that isn't `?`.

We unanimously preferred Z. `??` can be read as *may be* (`?`) nullable (`?`). 

## Conclusion

Comparing the two approaches we do favor solution 2, adopting the syntax `T??` to mean "the type of `default(T)`" (when `T` is unconstrained). We do think that this is the best solution, because it addresses both problems, is terse, and looks reasonable. We will move ahead with prototyping and fleshing it out.

We would probably only allow it to be used at all on type parameters `T` that are not constrained to be either value or reference types. That way you can never use either `??` or `?` on the same thing.

