Hacker News Reader

Comment by wongarsu | Hacker News Reader

Java and C# famously solve this with a hidden implicit return value for errors: the exception. The current trend in language design is to take the same idea and make it explicit instead, using sum types. Like Rust's `Result`, where the result contains either the normal value or an error, but never both

Of course C++ gives you the option to do any of the above, and still contains insane API contracts

View on HN

Arguably the better solution compared to these "algebraic sum types" (they go by countless different names) are set-theoretic union types, used by a few languages such as TypeScript.

They allow for types like "String or Integer". A function which returns a value of type "A" can automatically also be assigned to a variable of type "A or B", and a function which accepts a parameter of type "A or B" can automatically also be passed a variable of type "A". This is not the case for algebraic sum types, which require somewhat inconvenient wrapping or unwrapping.

Unlike algebraic sum types, set-theoretic union types are also not necessarily mutually exclusive. E.g. a number of type "Integer or Float" could be both. Moreover, set-theoretic types can be generalized to arbitrary Boolean combinations of types, e.g. "A or (B and not C)", possibly involving disjunctions, conjunctions, and negations (since {and, or, not} are functionally complete). That's not possible for algebraic sum/product data types. Though there is no mainstream language yet with a set-theoretic type system that supports negation types.

This choice has nice ergonomics but brutal practical cost so that's why languages close to the metal do not want to do this and particularly don't want to go around defaulting to it whereas a language like Typescript is fine with it.

Maybe it has "brutal practical cost", I don't know, but even most high-level languages don't have set-theoretic type systems. Perhaps because the approach is relatively new and most popular languages are old.

the set theoretic type system variant has one issue I think the algebraic one avoids: An overlap between types is ambiguous, i.e. "int | int" doesn't make any sense to write. In a function parse_postal_code, where you either get the postal code, or an error code you wouldn't be able to differentiate. You could write your own types for that, but now you've essentially recreated what the algebraic versions do by forcing a selection through the type constructor on the inner type instead of the wrapping union type.

That being said, in cases where there is no overlap I don't see why "the old way" shouldn't behave like typescript through implicit conversion as there is only one applicable constructor. Forcing explicit selection if there is overlap, but do it automatically when there is none seems like reasonable behavior that is a strict superset of what you wrote before.

Sum types in the set theoretic approach can be made with `(A & ¬B) | (¬A & B)`, or equivalently `(A | B) & (¬A | ¬B)`.

There's no mainstream language with negation types, but a few good research languages with them, eg MLstruct.

[MLstruct]:https://github.com/hkust-taco/mlstruct

> MLstruct supports union, intersection, and complement (or negation) connectives. We make sure they form a Boolean algebra and add enough structure to derive a sound and complete type inference algorithm. For more details, please see the paper mentioned above.

This is cool. Unfortunately it's also too late now. The machines have taken over programming.

Was it ever about the language? Or was it really about, what kind of special interests can be tickled in the authors of greenfield, free software?

Programming language development has essentially ceased, no? Because now that you have a super powerful, ceaseless special interest personality that can be ordered to be specially interested in any problem. The actual problem - a dearth of things that special interest personalities will do for little to no money - has been solved.

Programming languages take decades to get traction. We've had LLMs capable of real software engineering for less than two years. It's way too early to make pronouncements about this.

i don't know, apple says, you must use XYZ to develop for the iphone, and overnight, people will use it. most people correctly view this stuff as a "parade of tedious obstacles."

it's not really about traction or adoption so much as it is, the average developer values an ecosystem of free shit to use to make money.

the slow part is, the decades-long pipeline that converts the finite number of specially interested people created every year into programmers who sit around and do stuff for giant corporations, practically speaking, for free. maybe that is way too cynical but am i wrong? LLMs have had a range of programming performances, but for the whole time they have existed, they have not had difficult personalities. which is far, far more valuable. the majority of people in the white collar workforce are there because they are, #1, pleasant to work with, not good at their jobs. and look, specially interested people, who will pay huge amounts of money in order to avoid contact with people, agree!

That doesn't solve the whole problem, though - as per the rule, "zero, one, infinity", you often want to return more than two values, and often none of them represents an error.

But Rust doesn't care how many things you want to return?

    fn six_numbers() -> (u8, u8, u8, u8, u8, u8) {
        (10, 20, 30, 40, 50, 60)
    }

    fn in_an_array() -> [u8; 6] {
        [10, 20, 30, 40, 50, 60]
    }

The return type must be sized, because otherwise how can we put that anywhere? But of course your answer can just be to put it on the heap inside a Box...

    fn heap_numbers() -> Box<[u8]> {
        let mut slice = Box::new_uninit_slice(6);
        slice[0].write(10);
        slice[1].write(20);
        slice[2].write(30);
        slice[3].write(40);
        slice[4].write(50);
        slice[5].write(60);
        unsafe { slice.assume_init() }
    }

C++ can do this as well with tuple unpacking. Rust copied it from C++.

It seems more likely that Rust, an expression language with pattern matching, has the thing which makes sense here because this is just a pattern match.

From Rust's point of view

    let (a, b) = function_which_returns_a_pair();

is not special compared to the idiomatic:

    while let Some(item) = stack.pop() { /* do stuff with items and the stack */ }

or if we hate tuples:

    let [a, b] = function_returns_an_array_of_two_items();

I'm not a C++ guy (aside from the odd patch to upstream projects) so maybe I'm missing something but are you talking about structured bindings? AFAICS those were added in C++17, so Rust had them for much longer. Besides, I would argue Python is the real inspiration for C++ here.

In Rust "tuple unpacking" is really just a special case of pattern matching, which is a far more powerful concept and was actually taken from OCaml.

I would not describe exceptions as return values. Speaking in a C context, exceptions are more like "longjmp" than "return".

They're both ! Exception are definitely viewed as an alternate communication channel. And stack unwinding is one aspect of the communication. See https://nedbatchelder.com/text/exceptions-vs-status#h_valuab... (and many other)

Reply on news.ycombinator.com