Difficulties with non-nullable types (part 2)

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

damien morton — Mon, 25 Apr 2005 14:13:17 GMT

http://research.microsoft.com/SpecSharp/

Spec# is an extension of C#. It extends the type system to include non-null types and checked exceptions. It provides method contracts in the form of pre- and postconditions as well as object invariants.

Vote #1 for Spec#

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

Udi Dahan - The Software Simplist — Mon, 25 Apr 2005 14:28:47 GMT

Just a minor correction - Derived doesn't actually derive from Base.

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

Stuart Ballard — Mon, 25 Apr 2005 18:09:17 GMT

public class Foo {
string! x;
string! y = x;
public Foo(string! name) {
x = name;
}
}

How on earth do you resolve that one...?

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

CyrusN — Mon, 25 Apr 2005 21:54:16 GMT

Udi: "Just a minor correction - Derived doesn't actually derive from Base. "

Nice catch. I've corrected it.

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

CyrusN — Mon, 25 Apr 2005 21:55:44 GMT

Damien: The problem with solutions like Spec# is that they don't necessarily solve the problems that i'm goign to be outlining here. So you can end up with NullReferenceExceptions at runtime. They set up a nice type system, but don't enforce that it always be maintained.

I'd like to include non-nullable types in C#, but actually have them completely working (which will take a lot more effort).

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

CyrusN — Mon, 25 Apr 2005 21:59:05 GMT

Stuart: "
public class Foo {
....string! x;
....string! y = x;
....public Foo(string! name) {
........x = name;
....}
}

How on earth do you resolve that one...? "

This would not be allowed. This can be rewritten as:

public Foo(string! name) {
y = x;
x = name;
}

And, as we can see, "x" is used before it is definitely assigned to with a valid value. This is the same as if you had written:

public void Bar() {
....string x;
....string y = x;
}

then this is just not allowed.

Does that make sense?

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

Stuart Ballard — Mon, 25 Apr 2005 22:33:00 GMT

It makes perfect sense, but it's inconsistent with the behavior of all other types in the language as it stands.

class Foo {
string x = y;
string y = x;
}

This is completely legal and sets x and y both to null.

It's not how I'd have designed the language in the first place, but it's how the language stands today, and naturally you don't want to break existing legal code, no matter how strange it is to write code that relies on such an obscure (mis)feature of initialization order.

So IMO it's a little hard to justify why that should be permitted but it should be illegal if the strings turn into string!s.

See my last few comments on the SDR post for more such scenarios and thoughts on this kind of issue.

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

CyrusN — Tue, 26 Apr 2005 00:01:22 GMT

Stuart: "It's not how I'd have designed the language in the first place, but it's how the language stands today, and naturally you don't want to break existing legal code, no matter how strange it is to write code that relies on such an obscure (mis)feature of initialization order. "

This wouldn't be breaking any existing legal code. :)

"So IMO it's a little hard to justify why that should be permitted but it should be illegal if the strings turn into string!s. "

Not really. The above is permitted because we have guaranteed that all constraints have been met before the use of the variables. Now, the ! just says that it needs to be initialized to something that isn't null before being used. This is identical to how locals must be proven to initialized before they're used.

"See my last few comments on the SDR post for more such scenarios and thoughts on this kind of issue."

Sure!

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

DrPizza — Tue, 26 Apr 2005 14:46:25 GMT

Personally, I've always found C# (and Java's) decision to construct classes more or less backwards to be rather weird.

In C++, there's no problem here. Derived::Derived() isn't called until Base::Base() has finished; this means that Derived's members aren't initialized until Base is done constructing. Virtual calls within Base::Base() call Base's version of the method, not the overridden one, because at the time of the call, you don't yet have a Derived (so can't call its methods), only a Base.

It also uses init lists to initialize its members, in preference to normal-looking (but actually special, under your scheme) initializations in the constructor body.

Even without calling base class constructors prior to derived class initialization, init lists would seem a good way of handling the situation.

Under such a system one would have something like:

public abstract class Base
{
public Base()
{
Setup();
}
public abstract void Setup();
}
public class Derived : Base
{
string! name;
public Derived(string! name_) : name(name_), base()
{
}
public override void Setup()
{
Console.WriteLine("Debugging Info: " + name.ToString());
}
}

Should be simple enough to diagnose (if it's not in the init list, it's not initialized, so either null-initialize (nullable) or compile-time error (non-nullable)), shouldn't require any special magic ("if it's in the constructor's body but before the base class call it has limited access to this), should extend existing constructs (C#'s rudimentary init list) instead of requiring new ones (explicit base constructor calls), should do the Right Thing, and shouldn't break any existing code.

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

DrPizza — Tue, 26 Apr 2005 14:58:06 GMT

(in addition to the rule that you can't access 'this' until all members are initialized)

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

CyrusN — Tue, 26 Apr 2005 20:38:10 GMT

DrPizza: Absolutely right. I had meant to make that part of my post, but totally forgot about it. I've added a small edit at the bottom to reflect this.

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

DrPizza — Wed, 27 Apr 2005 02:44:12 GMT

"One thing I don't like is how C++ initialization lists look. I'd like to come up with a nicer looking syntax for that."

Well, you guys already copied them for base class constructor calls. Personally, I like distinguishing between assignment and initialization. It angers me that in C++ you can write:

Foo x = y;

and rather than calling Foo::operator=(y) (which is, let's face it, what it looks like) you're actually calling Foo::Foo(y). So I always use initializers anyway (that is, I'd write Foo x(y);). Since init lists are consistent with this syntax, they don't seem too problematic to me.

But... yeah. I've never really understood the rationale behind the backwards construction. I guess C# and Java treat the object as a finished object _prior_ to calling the constructor, whereas in C++ the constructor really _does_ "construct"; until Foo::Foo is completed *it's not yet a Foo*. Whereas in C# and Java, it's a Foo straight away, and the constructor is more of an "initializer" than a "constructor". I haven't really explained that very well.

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 2)

Luke — Fri, 29 Apr 2005 20:00:09 GMT

So, the fundamental problem is that while value types can be initialized to a default non-null value, there is no suitable non-null value to use for reference types. It becomes particularly apparent when you consider abstract reference types like interfaces. So, the discussion has been about somehow ensuring that before being used, non-nullable reference types are initialized to a non-null value, by other code, since initialization cannot be done automatically.

Let me throw out another idea totally distinct from this. Take a lesson from the way structs solve the problem. Say we allow non-nullable types to be null, which is their initial value, but the behavior of a null value is different. If _foo is null and you do _foo.Bar, instead of immediately getting a null reference exception, the call goes through with a null "this" pointer. Perhaps a type would specify static methods or a concrete derivative type to be called when "this" is null.

Then you could say:
string foo = null;
int x = foo.Length; // throws
string! bar = null;
int y = bar.Length; // y = 0

So, instead of running away from the null we always begin at, we simply make null not be null anymore.

I haven't throught this all the way through, but it's an interesting idea.

I want non-nullable types in C#4

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

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