Non-nullable types

re: Non-nullable types

Stuart Ballard — Thu, 13 Oct 2005 20:46:02 GMT

The idea of supporting three types of reference is an interesting one; presumably they'd be string! (non-nullable) string? (explicitly nullable) and just plain string (unchecked).

You could then arrange for any use of an unchecked type to produce a warning, which developers could choose to configure as an error instead using existing warn-as-error compiler settings.

For value types the "!" would be redundant, but it seems to me it would be a good idea to allow it for consistency, and also support producing a warning if it's not used. This would actually make the current inconsistent behavior of nullable value types more consistent - currently you can't call methods on the underlying type directly on a nullable, but that would be the case on an explicitly-nullable reference too.

re: Non-nullable types

Lonnie McCullough — Mon, 10 Oct 2005 23:40:36 GMT

Better yet, the "required" constraint could just force the compiler to insert checks against null to all the required parameters, throwing ArgumentNullException as appropriate. The "required" constraint would be visible in the editor through syntax assist, but would not really modify the type signature of the method because the null checks are performed by the method itself.

re: Non-nullable types

MSDNArchive — Mon, 10 Oct 2005 23:39:47 GMT

Thanks for your comments, Stuart. Backward compatibility is a difficult issue. The way Spec# in particular deals with it is to allow you to compile old code as C# but create a separate interface with updated signatures for these methods that is used by new code. They call these out-of-band specifications, and this is how they added non-null argument types to Framework methods.

One alternative solution more suitable for direct inclusion in C# is to create three types of references: non-nullable, nullable, and unchecked. The original syntax would produce unchecked references, which are nullable and can also be implicitly narrowed to non-nullable values. I'm sure there are other solutions available as well.

re: Non-nullable types

Lonnie McCullough — Mon, 10 Oct 2005 23:35:49 GMT

I think this would be a great addition to C#. Parameter modifiers that affect the actual type signature already exist in the "ref", "out" and "params" keywords. That last one is probably the closest in nature to the non-null type modifier because it requires compiler support to implement properly. Something like the following would be in keeping with C#'s nature:

public void Method( required string name ) {
}

The compiler could then use static checks to determine if Method or some other override (that doesn't include the "required" constraint) should be called. I definitely like putting basic constraints like this in the method signature itself. It also saves a lot of checking against null. Since the constraint modifies the signature of the method it would be easy to add these to current classes, while maintaing back-compat. Would also be cool if you could call:

obj.Method( required param )

and have the compiler perform the null checks for you. Makes calling the constained method from non-constrained overloads very easy.

-Lonnie

re: Non-nullable types

Stuart Ballard — Mon, 10 Oct 2005 22:50:25 GMT

See Cyrus's blog entries from a few months back on why this is a good idea, but also why it's hard.

My personal opinion is that it's impossible to do in C# because you can't do it *right* without breaking backward compatibility.

Consider the simple example:

public int GetLength(string s) {
return s.Length;
}

This is valid C# code today; backward compatibility dictates that it must continue to be valid and do the same thing it does today. But it instantly defeats the whole point of compiletime null checking because you have a possibly-null object being dereferenced right in front of your face.

It's possible to arrange that you can't pass a null value to a function that specifically requests a string!-typed argument, but that doesn't help much if every single "." in your program is still a potential landmine...