Difficulties with non-nullable types (part 3)

re: Difficulties with non-nullable types (part 3)

Gatsby — Tue, 26 Apr 2005 09:40:12 GMT

You could make it illegal to reference a non-nullable static within a static constructor, thus breaking the dependency cycle.

re: Difficulties with non-nullable types (part 3)

CyrusN — Tue, 26 Apr 2005 10:09:16 GMT

Gatsby: If we didn't allow access to the static fields in the static constructor, then how would we initialize the fields?

Note, if you have:

public static string! name = new Cyrus().name;

then that code in the initializer just goes into the static constructor.

So, without the static constructor, there is no way to initialize the static non-nullable fields. And if you don't initialize them, then they certainly won't be "not" null :)

re: Difficulties with non-nullable types (part 3)

CyrusN — Tue, 26 Apr 2005 10:09:46 GMT

Gatsby: If we go down that path, that seems like my first option which is to just not allow non-nullable statics.

re: Difficulties with non-nullable types (part 3)

Gatsby — Tue, 26 Apr 2005 10:31:04 GMT

Sorry, let me make that more precise: "In a static constructor, you cannot have anything non-nullable in the RHS of an expression, which cannot be proved to be non-null." This doesn't stop you from assigning to A.staticNonNullableVar in the static constructor of A.

However one variable that can't be proved to be non-null in your example is Person.name, namely because we can't know at compile time that Person hasn't been initialized yet. So in general, referencing non-nullable statics of other classes would not fly.

Make sense?

re: Difficulties with non-nullable types (part 3)

Gatsby — Tue, 26 Apr 2005 10:32:46 GMT

And by 'RHS of an expression' I meant right hand side of an assignment operation. :)

re: Difficulties with non-nullable types (part 3)

CyrusN — Tue, 26 Apr 2005 11:27:12 GMT

Gatsby: So how do you initialize the value then? :)

If you can't have a non-null value on the rhs, and that's *exactly* what you need to assign into the static field... then it seems like you're S.O.L. :)

re: Difficulties with non-nullable types (part 3)

Kamil Skalski — Tue, 26 Apr 2005 14:32:05 GMT

Well, I suppose that assigning an external non-nullable or literal isn't the only way to initialize the field. What about

string! a;

static Class () {
string x = Foo ();
if (x != null)
a = x;
else
a = "error?";
}

I guess this kind of assigning to non-nullable types is a *must*, otherwise the only values inside the non-nullable types would have to be literal... or values obtained from external function, which would break static verifyability.

I'm a *great* fan of non-nullable types, because they allow to natually use the framework to implement ML-like option['a] type. Simply None() becomes null and Some(x) becomes x - no need to create a wrapper. Of course we can do it now, but obviously we cannot expect compiler to forbid/warn about usage of A as A! (that is fetching element from option value).

If entire BCL were decorated with non-nullable types, then we could utilize nullable types as 'unsure' values, which compiler would force/suggest to check before usage.

StringBuilder! x = StringBuilder ("");
string! s = x.ToString ();
...
string line = buffer.ReadLine ();
// warning, line might be null
Console.WriteLine (line.Substring (1));

This is one of the those changes, which must be made *globally* in order to be usable, but then they will rule :-) (just like generics)

re: Difficulties with non-nullable types (part 3)

Ron Buckton — Tue, 26 Apr 2005 17:32:24 GMT

You could require that all non-null reference types are assigned a default value at declaration. It would incur a penalty of the overhead of instantiating a possibly unneeded reference type but all of these other issues would be moot.

Possibly not the best suggestion but its worth considering.

re: Difficulties with non-nullable types (part 3)

CyrusN — Tue, 26 Apr 2005 20:46:29 GMT

Kamil: "Well, I suppose that assigning an external non-nullable or literal isn't the only way to initialize the field. What about

static string! a;

static Class () {
...string x = Foo ();
...if (x != null)
......a = x;
...else
......a = "error?";
}
"

The problem with this is that Foo() could execute arbitrary code. That code could then end up trying to use "a" before it had been initialized. Not good!

"I guess this kind of assigning to non-nullable types is a *must*, otherwise the only values inside the non-nullable types would have to be literal... or values obtained from external function, which would break static verifyability. "

Yup. And that limits the usefulness if we only allow non-null literals. That means that all you can pretty much have are non-null strings :(

re: Difficulties with non-nullable types (part 3)

Joe Duffy — Wed, 27 Apr 2005 06:25:24 GMT

This is something Haskell got right and C[++|#|blah] got wrong. Nullability should be completely opt-in. Maybe<T> = Just T | nil works for me.

Nullable<T> is close. But not quite.

With that said, I love the idea of pre-/post-/invariant-condition annotations to the C# syntax. This is a great use of that style of programming.

Of course, flippant, off topic crap like this probably isn't helpful. Nonetheless, great set of posts. Keep it coming.

re: Difficulties with non-nullable types (part 3)

Joe Duffy — Wed, 27 Apr 2005 06:26:24 GMT

By the way, if it wasn't obvious: the "flippant, off-topic crap" comment above was in reference to my comment--not your post. :)

re: Difficulties with non-nullable types (part 3)

CyrusN — Wed, 27 Apr 2005 08:32:28 GMT

Joe: "This is something Haskell got right and C[++|#|blah] got wrong. Nullability should be completely opt-in. Maybe<T> = Just T | nil works for me."

I have to disagree with taht Joe. The Haskell style of Maybe (also known as "Optional", or in
other funtional languages) is a distinctly differnt concept than Nullable vs. Nonnullable in OO languages. In OO Nullable follows the "is a" relationship. So Nullable<T> is-a T. In Haskell/Scheme/Ocaml, this is not the case with Maybe. A Maybe<int> is not an int.

Note: in C# i have my own "Maybe" class (which i call "Optional"). I blogged about this before on this blog. However, it serves a very different purpse than nullable.

"With that said, I love the idea of pre-/post-/invariant-condition annotations to the C# syntax. This is a great use of that style of programming. "

Cool :)

Difficulties with non-nullable types (part 4)

Cyrus' Blather — Wed, 27 Apr 2005 09:36:34 GMT

So far i've discussed two interesting problems that arise when you try to add non-nullable types to C#...

re: Difficulties with non-nullable types (part 3)

joc — Wed, 27 Apr 2005 15:39:29 GMT

In static constructors you could disallow access to static non-nullable fields (as well as static non-nullable properties, functions with static non-nullable return types or non-nullable out and ref parameters) of other types: e.g. inside the static constructor of Cyrus, the static fields of Person would not be accessible.

re: Difficulties with non-nullable types (part 3)

Joe Duffy — Wed, 27 Apr 2005 20:41:56 GMT

Cyrus, I know nullability in OO differs from optionality in most functional languages. My point is that optional makes a helluva lot more sense than nullable baked into the type system.

Null of T should never be considered to be a real T. That's ludicrous--it isn't true, first of all... I think type systems should not be in the business of lying--and gives way to crap like NullReferenceExceptions.

I prefer to fix these styles of errors in the static type system than let dynamism run a good program at runtime. But nowadays, that seems to be an old skool point of view.

re: Difficulties with non-nullable types (part 3)

CyrusN — Wed, 27 Apr 2005 22:33:25 GMT

Joc: "In static constructors you could disallow access to static non-nullable fields (as well as static non-nullable properties, functions with static non-nullable return types or non-nullable out and ref parameters) of other types: e.g. inside the static constructor of Cyrus, the static fields of Person would not be accessible."

If you disallow all that... then how do you initialize your static fields? :)

You're basically disallowing me from touching any type that might transitively touch a type with a static initializer. This will be very constraining.

re: Difficulties with non-nullable types (part 3)

CyrusN — Wed, 27 Apr 2005 22:41:24 GMT

Joe: "Null of T should never be considered to be a real T. That's ludicrous--it isn't true, first of all..."

Well... i compeltely agree :)

Sorry if i ever let you think otherwise. However, non-null of T should be considered to be a real T.

"I think type systems should not be in the business of lying--and gives way to crap like NullReferenceExceptions."

And Some of T and nil give way to "MissingMatchException" in functional languages :)

"I prefer to fix these styles of errors in the static type system"

So do i. that's why i'd like to bring good old non-null types to C# and let people use Optional/Maybe to allow for null values. However, i'm running into many problems trying to do that, and i thought i'd share it with you. It sounds like we feel very similarly about this stuff, and i'm trying to get a ebtter solution so that if you *have* to use C# it doesn't end up totally pissing you off :)

"than let dynamism run a good program at runtime. But nowadays, that seems to be an old skool point of view"

Well... i'm trying to remove dynamism. but it's hard when the entire system is based around it :(

re: Difficulties with non-nullable types (part 3)

Joe Duffy — Thu, 28 Apr 2005 05:34:23 GMT

Cyrus, cool... think we're on the same page. Although we may differ in that I think nullability should be opt-in rather than opt-out.

In Haskell for example, forcing people to unbox a "Maybe of a" makes them realize they have to deal with the null case, or pushes it onto the caller if it understands only an "a"... (i.e. not nullable) And with pattern matching it becomes so much simpler than doing null branch testing to avoid sporadic NullRefExceptions.

re: Difficulties with non-nullable types (part 3)

joc — Mon, 02 May 2005 18:39:53 GMT

Joc: "In static constructors you could disallow access to static non-nullable fields (as well as static non-nullable properties, functions with static non-nullable return types or non-nullable out and ref parameters) of other types: e.g. inside the static constructor of Cyrus, the static fields of Person would not be accessible."

CyrusN: "If you disallow all that... then how do you initialize your static fields? :)"

With your static constructors! Person's static constructor is allowed to initialize Person's static non-nullable fields and Cyrus' static constructor is allowrd to initialize Cyrus' static non-nullable fields but you may not use the former to initialize the latter and conversely.

re: Difficulties with non-nullable types (part 3)

Beijing hotels — Wed, 22 Feb 2006 13:09:32 GMT

Beijing hotels

I want non-nullable types in C#4

Patrick Smacchia — Wed, 25 Jul 2007 20:26:41 GMT

There is no-doubt that the C#2 nullable-types is a cool feature. However I regret that C# don't support