Remix clone Hacker News

new | show | ask | jobs Github

▲

imbnwa 5 hours ago

They really ruined Optional not solving this then and there

▲ cogman10 5 hours 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 5 hours 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 5 hours 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 4 hours 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.

▲ thrw42A8N 5 hours 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.

▲ 5 hours ago | parent | prev [-]

[deleted]