They really ruined Optional not solving this then and there

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

▲ 7 months ago | parent | prev [-]

[deleted]