11–20 of 164 posts
I think the nullable reference type system in c# is a perfectly workable compromise for languages that had nullability from the very beginning. Once a code base uses them fully, most null-related bugs are gone. And it’s far from an unwieldy bolt-on.
I don't actually think it solves any problems. You still have to null check.
String foo = null;
String bar = "";
foo.equals(bar) --> true
EDIT: I'm blocked from posting so I won't be responding further, thank you for discussion.
> The {@code Void} class is an uninstantiable placeholder class to hold a reference to the {@code Class} object representing the Java keyword void.
When Java introduced Generics they re-used "Void" type. Method calls need to use "null" when "Void" is the type. So in a way, "type of null" is "Void".
Doesn't an Optional basically cover this case
An Optional is just a tri-valued null (null, None, and Some), so no. It'd be nice if Java had a concept of a never-null reference (like a C++ reference vs. a C++ pointer), but the @NotNull annotation wasn't enforced the last time I checked. Also, there's no way for an object to express that invariant because encapsulation is so weak. Given only this constructor (and no reflection): Foo() { foo.bar = new Bar(); /* foo…
I think the nullable reference type system in c# is a perfectly workable compromise for languages that had nullability from the very beginning. Once a code base uses them fully, most null-related bugs are gone. And it’s far from an unwieldy bolt-on.
The Nullable class is nice and I love to use it but it would be even better with an option type like in F#
I don't actually think it solves any problems. You still have to null check.
null would just mean the zero value instead of the absence of a value String foo = null; String bar = ""; foo.equals(bar) --> true This works well provided the data type has a sensible zero value like collection types EDIT: I'm blocked from posting so I won't be responding further, thank you for discussion.
Doesn't an Optional basically cover this case
An Optional is just a tri-valued null (null, None, and Some), so no. It'd be nice if Java had a concept of a never-null reference (like a C++ reference vs. a C++ pointer), but the @NotNull annotation wasn't enforced the last time I checked. Also, there's no way for an object to express that invariant because encapsulation is so weak. Given only this constructor (and no reflection): Foo() { foo.bar = new Bar(); /* foo…
Earlier quoted context omitted.
An Optional is just a tri-valued null (null, None, and Some), so no. It'd be nice if Java had a concept of a never-null reference (like a C++ reference vs. a C++ pointer), but the @NotNull annotation wasn't enforced the last time I checked. Also, there's no way for an object to express that invariant because encapsulation is so weak. Given only this constructor (and no reflection): Foo() { foo.bar = new Bar(); /* foo…
null can be avoided with a good linter
I don't actually think it solves any problems. You still have to null check.
Kotlin solved Java's problem by making it a compiler error if a value that can be null isn't checked and shown to be null or the actual value, eliminating an entire class of exceptions.
Ruby has a `NilClass` and the best/worst part of it is the to_s is "", to_i is 0, to_f is 0.0, to_a is [], to_h is {} It's incredibly clean and convenient until you wake up one morning and have no idea what is happening in your code