Added: LDM notes for July 11th, 2018

[agocke]

See https://github.com/dotnet/csharplang/blob/master/meetings/2018/LDM-2018-07-11.md

Agenda

1. Controlling nullable reference types with feature flags
2. Interaction with NonNullTypesAttribute
3. Feature flag and 'warning waves'
4. How 'oblivious' null types interact with generics
5. Nullable and interface generic constraints

[gafter]

Regarding

What does the following do?

void M1<T>(T t) where T : I, T : class?

This is a warning or error, because T : I implicitly means that I is a non-nullable type and class? is a nullable reference type. The constraints are contradictory.

I disagree that these constraints are contradictory. These constraints are compatible because there exist type arguments that satisfy both constraints (e.g. string). That is because a non-nullable type is a subtype of a nullable type. Nevertheless, I agree that a warning is helpful because the ? in the constraint has no effect on the meaning of the method.

[DavidArno]

Edited in light of @orthoxerox's comments below

I think the NonNullTypesAttribute idea is heading in the right direction, but is still not quite there.

Firstly, some means of applying this attribute to the whole project is needed. I'm unclear whether that's currently possible. If it is, great. If not, a means of applying it is really needed as it'll be a nuisance to have to add it everywhere.

Secondly, I want to be able to treat parameters as non nullable and return types as nullable for unannotated assemblies. So I think an enum is needed:

enum UnannotatedTypesBehaviour
{
    Oblivious,
    NonNullable,
    Nullable
}

With the resultant table being:

	Warning	No warning
NonNullable	C# 8 feature on, unannotated types are non-nullable	C# 8 feature off w/ suppress
Nullable	C# 8 feature on, unannotated types are nullable	C# 8 feature off w/ suppress
Oblivious	Null/non null state of unannotated types determined by the call site	C# 7

[orthoxerox]

Secondly, I want to be able to treat parameters as non nullable and return types as nullable for unannotated assemblies.

How will treating parameters as non nullable help you? First of all, this is not 100% true, and second, it will only trigger the warning if you explicitly use nullable variables in your own code (and I expect your code to contain very few nullable variables 😁). It will also trigger if you use code like LibraryX.Foo(LibraryX.Bar()), which will be extremely annoying.

[DavidArno]

@orthoxerox,

That was my thoughts too. But I assume we are being offered two options (oblivious and treat as non-nullable) for a reason. I want to be able to treat returns as nullable. Parameters aren't so important. So I tried to make as small a change from what was proposed as possible. Treating everything as nullable would work too.

Having said that, treating parameters as non-nullable has the advantage that I must explicitly mark parameters with a ! if I want to pass a null. So it actually offers the most safety by generating the most amount of warnings. It'll contain many false positives, but that's a price worth paying in my view. It's an extreme setting for those that want the maximum null-safety.

[DavidArno]

@orthoxerox,

Your LibraryX.Foo(LibraryX.Bar()) is a good one, so I've updated my comment to propose a simple treat unannotated types as nullable/non-nullable switch.