Non-nullable reference types

re: Non-nullable reference types

Remco — Thu, 15 Jan 2009 14:17:41 GMT

John,

Nice example of dealing with input requirements.

However, i think it suffers from one problem: the exceptions that get raised have an "unexpected" stack trace. It wil report the call site (technically) correct as:

Value cannot be null.

at TestApp.NotNull`1..ctor(T value) in C:\Temp\NonNullable\TestApp\TestApp\NotNull.cs:line 16

at TestApp.NotNull`1.op_Implicit(T value) in C:\Temp\NonNullable\TestApp\TestApp\NotNull.cs:line 37

at TestApp.ReverseNotNullDemo.Run() in C:\Temp\NonNullable\TestApp\TestApp\ReverseNotNullDemo.cs:line 13

However, the upper two lines in the stack trace only confuse the troubled location. The problem exists in the call at line 3. I would like to see:

Value cannot be null.

at TestApp.ReverseNotNullDemo.Run() in C:\Temp\NonNullable\TestApp\TestApp\ReverseNotNullDemo.cs:line 13

Now, I've used Delphi in an earlier life, and there you could use:

raise Exception.Create() at $address

If you had enough information about the call stack, you could trigger the exception at the troubled location, instead of the reporting line.

Do you think something like that is possible in C# / .Net?

re: Non-nullable reference types

skeet — Fri, 12 Dec 2008 06:32:21 GMT

@Johannes: Sorry I didn't see this reply before. I must have approved it but not had the time to look at it properly. Nice work!

re: Non-nullable reference types

Johannes Hansen — Tue, 21 Oct 2008 18:32:15 GMT

Hi Jon,

thanks for this great little utility class I'm sure it will help us avoid many common errors in our internal libraries in the future.

There is a problem with your solution however... Since you are using a struct (which you should) you also get a default parameterless constructor that lets a user circumvent the null check in the other constructor. the problem is that you can't redefine this default constructor via. c# code. So I took the liberty to make a similar implementation where I've modified the IL to throw exception if you call the default parameterless constructor, it has also been marked as obsolete (error=true) to have a better design time experience for the developer.

You can get a copy from:

cid-f61a12f6f7c6dd75.skydrive.live.com/.../NonNull.zip

Hope you like it.

By the way, this is also being discussed on C9:

channel9.msdn.com/.../407089-Non-null-in-C

re: Non-nullable reference types

Vladimir Kelman — Tue, 21 Oct 2008 04:21:06 GMT

John, could you explain in a bit more details why is it worse to specify it as

public class NonNullable<T> where T : class {} ?

To avoid referencing an original value we could use Object.MemberwiseClone() in a constructor:

public NonNullable(T value) {

if (value == null) {

throw new ArgumentNullException("value");

}

this.value = value.MemberwiseClone();

}

This would make unnecessary if (value == null) check in a getter.

re: Non-nullable reference types

Weeble — Wed, 15 Oct 2008 13:59:57 GMT

Hehehe. I asked a very similar question on microsoft.public.dotnet.languages.csharp last year, but I didn't really get much response. I've linked to the post if you click on my name. It's frustrating that there really no good option at the moment, pick one of: masses of null-checking boilerplate code in all your methods; hard to debug NullReferenceExceptions; clever but awkward semi-kludges such as this.

re: Non-nullable reference types

Abraham Pinzur — Tue, 07 Oct 2008 17:33:54 GMT

I created a similar struct type and have been experimenting with it for almost a year. I love the idea of a self-documenting mechanism for declaring method preconditions, class invariants, etc..

In hopes of keeping the impact to surrounding code as small as possible, I (like you) made both conversion operators implicit. Unfortunately, without language support, I've still found myself forced to think far too frequently about conversions to and from NonNullable<T>. For instance:

1. Accessing the methods (and properties) of a NonNullable object requires ubiquitous usage of the Value property or an explicit cast. (I quickly gave up on using this for fields and properties.)

2. Casting from one NonNullable type to another is cumbersome. For instance, if class B derives from class A, then I should be able to substitute a NonNullable<B> wherever the code expects a NonNullable<A>. However, given C#'s lack of support for generic type covariance, I'm once again forced to use an explicit cast to class A.

Perhaps someone has some suggestions for improving usability around a type like this?

re: Non-nullable reference types

skeet — Tue, 07 Oct 2008 14:35:12 GMT

@Larry: Such is the downside of blogging in a relative hurry :)

I'm not sure that it's feasible to introduce Spec# compile-time requirements at this point in time - it's like introducing const-correctness into an existing library. Who's going to go over all of your code to change all the signatures?

I don't *think* any of this is likely to come in C# 4 - which is likely to be a relatively small set of enhancemenets anyway - but there's certainly stuff the compiler could do to at least enforce constraints at execution time without as having to laboriously write out all the pre/post-condition checking manually. Maybe C# 5...

re: Non-nullable reference types

Larry Smith — Tue, 07 Oct 2008 14:26:20 GMT

I'm surprised you didn't mention Spec# or Sing#, both internal variations of C# created by Microsoft. (Singularity, Microsoft's experimental operating system, is written in Sing#.) IIRC, they both allow you to write, say, <string! s = "foo";>, where the "!" specifies that <s> is guaranteed to be non-null. With this declaration in hand, the compiler can (and, I think, does) ensure that nowhere throughout the entire application (including subroutine parameters (suitably declared with !'s themselves)) can't be null, else you'll get a compile-time error.

I'm hoping, verging on expecting, that this (and other Spec# features) will be part of C# 4.0.

re: Non-nullable reference types

Nicholas Blumhardt — Tue, 07 Oct 2008 14:18:38 GMT

Neat. I'd call it Required<T> though :)

re: Non-nullable reference types

skeet — Tue, 07 Oct 2008 09:46:56 GMT

@Drakiula:

There's still the problem of not being able to specify a parameterless constructor. Also, the constraint is quite a restrictive one and I suspect wouldn't actually be what you wanted very often. It would also involve creating far too many instances of T for no reason!

re: Non-nullable reference types

Drakiula — Tue, 07 Oct 2008 09:41:40 GMT

Sorry again ...

re: Non-nullable reference types

Drakiula — Tue, 07 Oct 2008 09:39:51 GMT

Sorry for double posting, I wanted to post

public NonNullable()

{

this.value = new T();

}

Alas, for this to work, the new() generic constraint for T would have to be added.

re: Non-nullable reference types

skeet — Tue, 07 Oct 2008 09:28:53 GMT

@Drakiula:

Firstly, you can't add parameterless constructors to structs. Secondly, that would have no effect anyway, as it would just set value to null (as that's the default value for all reference types).

re: Non-nullable reference types

Drakiula — Tue, 07 Oct 2008 09:22:47 GMT

How about adding

public NonNullable()

{

this.value = default(T);

}

re: Non-nullable reference types

James Hart — Tue, 07 Oct 2008 08:59:29 GMT

Neat. I think the problems you've listed - that default instances and values returned by the parameterless constructor are null values - make calling the type 'NonNullable' a bit optimistic, however.

But as a way of automating null-checking on a parameter, this is pretty neat, actually, thanks to the implicit conversion operators - has an aspect-oriented flavour to it. Maybe the name should be changed to be more appropriate as a type declaration in an argument list - NotNull<string> perhaps?

re: Non-nullable reference types

Wedge — Tue, 07 Oct 2008 07:24:23 GMT

I wonder how you might use this sort of thing to better facilitate the Null Object pattern. I can see how a static method in an interface might be worthwhile now. I suppose you could use reflection to hack in some kind of duck-typing in order to get at a static factory method that returned a null object reference for the type.

It's a shame C# doesn't have typedefs, done right this pattern could be really slick.

re: Non-nullable reference types

skeet — Tue, 07 Oct 2008 05:25:06 GMT

Eddie/Jay: This is a struct. The default value (and the result of calling the parameterless constructor) will wrap a null reference.

Elij: You can't overload the equal operator - but the implicit conversion will make your code blow up appropriately.

Jay: Even for trivial values, I prefer properties over public fields. The only time I ever expose public fields is for constants, and even then I'm somewhat leary.

re: Non-nullable reference types

Jay Bazuzi — Tue, 07 Oct 2008 05:10:47 GMT

I like it.

Two concerns:

1. Why does the Value property bother checking for null & throwing? Haven't you already confirmed non-null in the constructor?

2. If the implementation of Value is going to be trivial, why bother with a property at all? I'd skip the property, make the field pubilc, and rename it to "Value".

re: Non-nullable reference types

Elij — Tue, 07 Oct 2008 03:32:13 GMT

Wouldn't you override the "equal" operator so that "NonNullable<T> blah = null" also throws an exception?

re: Non-nullable reference types

Eddie Velasquez — Tue, 07 Oct 2008 00:22:59 GMT

Isn't the null check in the Value property getter redundant? The only way that value is set as far as I can see is through the constructor, which checks for null.