Hacker News Reader

Comment by Someone | Hacker News Reader

That rabbit hole leads you to have separate types for collections with 0, 1, 2, etc. elements.

You need collections with two elements, for example to ensure that

   items.dropFirst().min()

   items.sort().take(2)

are safe to call.

Because of that, I think having min() return Either(int,error) is the way to go for most languages (‘researchy’ languages can be an exception)

Enforcing abs to work for all integers would be higher on my list. Are there any languages that have INT_MAX == -INT_MIN and interpret 0x80…0 as ‘Not a Number? That could be used as return value for min() on empty sequence, too.

View on HN

> think having min() return Either(int,error) is the way to go for most languages

What about languages that want to be efficient? It's much more efficient to use a int return value then to unwrap it. Efficiently is one of the main goals of this language (Efficiently, safety, syntax/readability)

Do you think enforcing that lists never are empty is more efficient?

If the language can prove the list is not empty, it can elide constructing that “Either” object and optimize away the caller’s error path.

If it can’t (and there will be lots of cases where it won’t be able to, even though it theoretically could), what will it do? Return an incorrect value, abort the program, refuse to run the code, something else?

Yes. It's done during compile time and trivial to do.

Changing the function signature is significantly harder. You'd either have to inline the function, evaluate the code, run optimizations to remove the Either wrapping or you can have a more specialize simple check and have two version of the function. One with the standard signature and one that doesn't use Either and modifies the function to not use it.

Having one function signature which you don't need to modify is significantly more simple than applying several optimizations to undo wrapping and not break anything

Reply on news.ycombinator.com