Added: C# LDM Notes for Jan 14th, 2019

[agocke]

https://github.com/dotnet/csharplang/blob/master/meetings/2019/LDM-2019-01-14.md

Agenda

• Generating null-check for parameter!
  Proposal: Proposal: Simplified parameter null validation #2144

[qrli]

There is a little overlapping between non-nullable reference type string and the parameter!.
Consider a method with multiple non-nullable parameters:

void F(string s1!, string s2!, string s3!, string? nullableS4) { }

It would be obvious that the ! is repeating what strings say, with the difference that it generate the null check. So, it feels like could be single notation to say, "I want null check for all my non-null parameters". e.g.:

[CheckNulls]
void F(string s1, string s2, string s3, string? nullableS4) {}
// or
void F(string s1, string s2, string s3, string? nullableS4)
    checked null
{ 
}

And this will be more inline with code contracts, if they will ever be in.

[theunrepentantgeek]

Note, they apply at different times.

The type string? is a compile-time clue to flow analysis. At run-time it's just a plain old string reference type, nulls and all.

The parameter s1! is a run-time check to throw an exception.

[qrli]

I know that. My point is that, when written at declaration site, for code readers, they convey duplicated and potentially conflicting message. E.g.

void F(string s1!, string s2, string s3!, string? nullableS4) { } // what happened to s2?

I'm trying to remove that duplication, while still keeping them as separate features, by writing whether a parameter is expected to be null only once.

[DavidArno]

@qrli,

If I may, let's take as read the statement, "NRT will be great for new code and will be hard to apply to existing code". It's a sweeping generalisation, but if we assume it's true then ! as a null check becomes very useful for existing code. I can use it for quick wins by removing lots of boilerplate code by decorating my parameters with !.

Having then got the code working reliably with no NRE's using !, I could then start turning on NRT. At that point, I'd likely start stripping out those null checks as the compiler is doing the checking for me instead. So I could see both features being useful, but for different types of code bases.

Obviously I've made a sweeping generalisation, and there will be existing code that can be switched to NRTs easily. But for code that fits the generalisation, ! would be useful.

I agree with you though that there seems little point mixing both auto-generated null checks and NRTs. An exception possibly being libraries that use NRTs but also want to maintain compatibility with code that doesn't.

[DavidArno]

void F(string s1!, string s2, string s3!, string? nullableS4) { } // what happened to s2?

F is using NRTs. s2 could be null, but there's no special treatment of null for that parameter. So it makes sense to mark it as string to help spread good practice of not using nulls. s1 and s3 will cause the function to fail if they are null, so we fail early with !. And nullableS4 is a special case that will treat null as a distinct value and change the functions behaviour if it is, so we explicitly mark it with ?.

It's an edge case but when the shape is millions of developers in size, the edge is large...

[Logerfo]

Q: Where is the null check for iterators?
A: Null check in the stub method, as soon as possible (before the yield).

Can I have some clarification on this? What does "stub" stand for, in this situation?

public static IEnumerable<T> M<T>(this IEnumerable<T> source!)
{    
    IEnumerable<T> m()
    {
        //null check here?
        foreach (var item in source)
            yield return item;
    }
    //or here?    
    return m();
}

[HaloFour]

@Logerfo

I took it to mean the second location, in that the iterator method would throw immediately and not on the first attempt to MoveNext(). Basically, "as soon as possible."

[quinmars]

@qrli With the damnit operator you are more flexible, especially when unconstrained generics are supported. Consider the following:

public void IDictionary<TKey, TValue>.Add(TKey key!, TValue value)
{
    ...
}

It's not clear if a checked null will cause both values/references to be checked or none, but you cannot define to throw only for the first one, as required here.

[quinmars]

And it is shorter for lambdas:

o! => o.Name

vs.

o checked null => o.Name

[qrli]

@quinmars Per my understanding, using ! for an unconstrained generic parameter will generate null check by C# compiler, regardless T being nullable or not, because it is the same function in IL. Ideally, the JIT should optimize it out for non-nullable (in IL sense but not C# sense) types.

That being said, your point is uncontrained generic parameter, where the type cannot be treat and non-nullable but the parameter expects to be non-null. I agree this is a possible scenario.

Nitpicking: I feel your example, TKey of IDictionary, is not quite valid. I'd think TKey should be constrained to non-nullable, in practice.

[qrli]

To be clear, I'm not against the feature. I really love this feature.
Just challenge the syntax a bit, so see if there can be an even better design.

[quinmars]

Nitpicking: I feel your example, TKey of IDictionary, is not quite valid.

Well, it is how Dictionary<TKey, TValue> works today, and probably will in future.

https://referencesource.microsoft.com/#mscorlib/system/collections/generic/dictionary.cs,319

[qrli]

Rethought over:

• The param! is, effectively, not only a null-check, but also a strong non-null notation.

• Different than NRT, which is about types, the param! is about parameter, like R#'s [NotNull]. It is also a different mechanism of non-null than NRT. It is better to merge into NRT.

• For lambda: I don't think it is neccessary in most cases, because lambda is typically used in a local context, where you control what you pass in as paramter. And in real world, I don't remember I have ever written a lambda checking parameter nulls. Though, there could be special cases for it.

Now, I'm inclined to the M(string! s) form in design notes, treating it as stronger form of M(string s).

M(string? s) // s is nullable
M(string s) // s is non-nullable but no check
M(string! s) // s is non-nullable and do check! 
             // In addition, s cannot be reassigned to null if NRT is turned on.

And this seems to also smooth out the unconstrained generic parameter case. And we can enable non-nullable for unconstrained generic parameter:

N<T>(T! v1, T v2) // v1 becomes non-nullable type, while v2 may be nullable

[Joe4evr]

using ! for an unconstrained generic parameter will generate null check by C# compiler, regardless T being nullable or not, because it is the same function in IL. Ideally, the JIT should optimize it out for non-nullable (in IL sense but not C# sense) types.

Yes, the JIT already removes null checks against value types in open generic types/methods, nothing new needs to happen in that regard.

[fanoI]

But the JIT will remove null check for "string x" too if NRT is enabled?

[YairHalberstadt]

@fanol
a) The JIT doesn't know about the existence of NRTs
b) NRTs are essentially a linter, to help the developer know which variables are expected to be null. It provides no guarantees that a non-nullable type is not actually null.

[agocke]

@Logerfo @HaloFour Correct, we will throw before constructing the enumerator.