5 ms·

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

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 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.

Groxx 16y ago
... 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.
- masklinn 16y ago
  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")
  - Groxx 15y ago
    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 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#VariantList http://msdn.microsoft.com/en-us/library/dd799517.aspx#Varian...
ssp 16y ago
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();
- Groxx 16y ago
  That seems like it would be a trivial thing to do in an early compilation step... why is the workaround necessary?
  - masklinn 16y ago
    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)
    - sirclueless 16y ago
      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.
      - masklinn 16y ago
        > 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.
bartwe 16y ago
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.

Groxx 16y ago

... 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.

masklinn 16y ago
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")
- Groxx 15y ago
  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 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#VariantList http://msdn.microsoft.com/en-us/library/dd799517.aspx#Varian...

ssp 16y ago

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();

Groxx 16y ago
That seems like it would be a trivial thing to do in an early compilation step... why is the workaround necessary?
- masklinn 16y ago
  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)
  - sirclueless 16y ago
    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.
    - masklinn 16y ago
      > 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.

bartwe 16y ago

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.