Hacker News Reader

Comment by snprbob86 | Hacker News Reader

Many language designers, including many on Microsoft's Managed Language teams, consider null reference and invalid cast exceptions to be huge blunders.

The "Nice" language shows that it's pretty easy to statically avoid this: http://nice.sourceforge.net/safety.html

The sad fact is that the Java and .NET base class libraries were designed before (1) generics and (2) a generic "Nullable" (aka "Option") type were available. Anyone designing a statically typed environment today should certainly include both and design a compiler to enforce their usage and safety.

View on HN

... but since 2.0 .NET can do all the things listed in that Nice document. There are glaring gaps in the core libraries, which tick me off to no end, but that has nothing to do with the language.

Nice is a language, not a VM, so I'm guessing you're talking about C#.

In which case... uh... no. Of Nice's "advanced safety features" it only got generics (in 2.0) and internal iterators (in 3.0, via LINQ methods)

* It's a single-dispatch language

* Its instanceof (`is`) is the same shit as Java's (and the compiler is just as stupid)

* Object types are always nullable, it's not optional and it's not opt-out

* Its arrays are covariant (covariant arrays were added to the CLR for java compatibility, and C# got them from there because it was "free")

VM vs language: not really. The version of .NET heavily defines the capabilities of the language, as it's also tied to a compiler, and multiple languages tend to get new features at the same time. e.g.:

>Generics are only supported on version 2.0 and above of the Microsoft .NET framework, as well as version 2.0 of the compact framework. [http://msdn.microsoft.com/en-us/library/aa479866.aspx]

The day Microsoft (or anyone else) allows you to create generics in the VM for 1.1, which is quite a different one than 2.0 and above, I'll happily admit I'm wrong.

Single vs multiple dispatch: yeah, you can fake it with reflection, but it's not part of the language feature.

Nullable: Good point, missed that part of the page. That would be nice.

IEnumerables are covariant in .NET 4, I missed the covariant part too: http://msdn.microsoft.com/en-us/library/dd799517.aspx#Varian...

The main problem with non-nullable types is that the static analysis involved doesn't work for object fields., so you can't write code like this:

        if (object.some_field != null)
               object.some_field.foo();

because the compiler is unable to prove that it's correct. Instead you have to do a clumsy workaround like this:

    SomeType some_local;

    some_local = object.some_field;
    if (some_local != null)
        some_local.foo();

That seems like it would be a trivial thing to do in an early compilation step... why is the workaround necessary?

1. properties mean field invocations are not referentially transparent (you can only mitigate this by removing properties, or having referential transparency as part of the type)

2. multithreading means the value of the field can change from under you between the check and the access (you can solve this by eliminating threads or by transactioning your accesses)

I'm pretty sure point 2 is incorrect. The compiler doesn't worry about multithreaded access to properties/variables when optimizing.

You're right that such access can cause problems though. If you do want the compiler to worry about multithreaded access when it compiles, you can use the `volatile` keyword.

> I'm pretty sure point 2 is incorrect. The compiler doesn't worry about multithreaded access to properties/variables when optimizing.

This is not about optimizing, it's about static verifications. And that's very much the point: you can't statically verify this piece of knowledge if the code can be used in a multithreaded context.

The problem is that if the code looks like this:

        if (object.some_field != null)  {
               some_unrelated_call();
               object.some_field.foo();
        }

proving that some_unrelated_call() didn't set object.some_field to null is very difficult.

In general, it's also difficult to prove that 'object' doesn't get set to null too.

Depends on what you mean by "general", I suppose, but if 'object' is a local variable in a Java-ish language, then there is a fairly straightforward data flow analysis that can do a good conservative estimate.

but if 'object' is a local variable in a Java-ish language, then there is a fairly straightforward data flow analysis that can do a good

But if it's not, and/or if it can be adress taken...

> The main problem with non-nullable types is that the static analysis involved doesn't work for object fields., so you can't write code like this

You shouldn't get to write code like that anyway. It's C. It's crap.

Here's what you write:

    object.some_field.notNull(f => f.foo())

and that's only valid if some_field is of type Nullable<whatever>.

If you have to check it for null then, by definition, some_field here isn't a nullable type. If it was, you'd just do:

    object.some_field.foo();

Am I missing something here?

C# (values) or Nice don't use a full, explicit nullable generic type, and instead tag the original type (`int?` for C#, `?String` for Nice).

This means some_field could be a type tagged as nullable (e.g. `some_field` would be defined as ?Foo).

An alternative would be `@NotNull` opt-in anotations, where `some_field` would not be tagged, therefore nullable, therefore could hold the value `null`.

Thus, if you have to check it for null then `some_field` is a nullable reference, in a language which may have nullable and non-nullable references.

Nonnullable (static) class fields and constructors don't mix however, which is why you don't see it as a language addition so far.

Nonnullable local variables and function parameters however could easily work within the current c# language.

Reply on news.ycombinator.com