> Both languages don't do much about Tony Hoare's Billion Dollar Mistake, and to me that's an immediate black mark on type safety, though they fail in this regard in distinct ways.

Java is well on its way to alleviating the problem. [1]

[1] https://openjdk.org/jeps/8303099

▲ baranul 9 months ago | parent | next [-]

Actually, a number of modern languages have addressed this. A few of them are: Dart, Rust, and Vlang. However, many of the newer languages seem to address or handle null (nil) safety, a bit differently from each other.

In Dart[1] and Vlang[2], for example, "non-nullable" is the default. Vlang doesn't allow null or nil to be used, unless code is marked as unsafe, and primarily only for compatibility with languages that do (like C). In Dart, nullable variables have `?` added to the end of them.

[1]: https://en.wikipedia.org/wiki/Dart_(programming_language)

[2]: https://en.wikipedia.org/wiki/V_(programming_language)

▲ imbnwa 10 months ago | parent | prev [-]

They really ruined Optional not solving this then and there

▲ cogman10 10 months ago | parent [-]

There would always be a hole that's somewhat impossible to fill with the language as is.

If you have something like

    Map<Integer, Optional<Integer>> map;
    var foo = map.get(1);

if `1` isn't present in the map then `foo` has to be set to something. It will be `null` in this case.

If the new null restricted stuff makes it in, you can express this as

    Map<Integer, Optional<Integer>!> map;
    var foo = map.get(1);

and yet, `foo` will still end up being `null` in that case (I assume) because something has to come back if `1` isn't present.

At best, that will prevent you from doing `map.put(1, null);`

▲ cobbal 10 months ago | parent | next [-]

I'm not completely sure what this example is trying to illustrate. Most languages with proper sum types would have `Map<K, V>.get` return an `Optional<V>`. If V happens to be `Optional<Integer>`, then the result will be an `Optional<Optional<Integer>>`, which is a perfectly good type that represents the two ways a value may be missing from the map.

Am I missing something?

▲ pbh101 10 months ago | parent [-]

The Map interface pre-dates Optional and does not return Optional, so it won't return an empty Optional but rather null.

To be more clear:

    Map<K, V>.get(foo)

returns a `V`, not an `Optional<V>`. If your `V` is `Optional<WrappedV>`, cool, but that doesn't change that `Map` either finds or doesn't find a V.

▲ stickfigure 10 months ago | parent [-]

The parent certainly knows this. Additional methods could be added to `Map` which return `Optional`. I am annoyed by their absence every day.

▲ pbh101 10 months ago | parent [-]

Maybe. They didn't seem to communicate any specific knowledge of the Java standard library. Agree an

    Optional<V> get(K)

sounds like an 'obvious' addition, though also I've found that when something 'obvious' isn't added to Java since 1.7, the explanation proffered makes sense to me.

	▲	cogman10 10 months ago \| parent [-]
		Java doesn't have return type function dispatch. If you had something like: `var x = map.get(k);` The type of `x` could not be inferred. The best they could hope for is a signature like `Optional<V> getOpt(K);`. Which wouldn't be terribly bad as Java currently has an annoying get definition in the `Map` interface because it predates generics (The current signature is `V get(Object)`). Regardless, if they do want to change the interface, it'd probably be best if they waited for Valhalla to land. One of the problems with `Optional` as it stands is it creates a load of GC pressure. If `Optional` is converted into a value class then there will be effectively no overhead to returning it everywhere.

▲ thrw42A8N 10 months ago | parent | prev | next [-]

The actual point is so that the compiler can tell you that you forgot to check all possible cases. Typescript is really great for this.

▲ 10 months ago | parent | prev [-]

[deleted]