4 ms·
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 (
by ssp 15y 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 15y agoThat seems like it would be a trivial thing to do in an early compilation step... why is the workaround necessary?
- masklinn 15y ago1. 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 15y agoI'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 15y 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.
- ssp 15y agoThe 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.
- kenjackson 15y agoIn general, it's also difficult to prove that 'object' doesn't get set to null too.
- ssp 15y agoDepends 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.
- kenjackson 15y agobut 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...
- masklinn 15y 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 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>.
- munificent 15y agoIf 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?
- masklinn 15y agoC# (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.