I share your distaste for arbitrarily renaming concepts. However, I think if you only have one of the two in the language, Optional is the clearer name.

A result is already the informal name of the outcome or return value of every regular operation or function call, whereas an Optional is clearly not a regular thing.

I also think, from a pragmatic systems-design point of view, it might make sense to only support the Either/Result pattern. It's not too much boilerplate to add a `faultdef KeyNotInMap`, and then it's clear to the consumer why a real answer was not returned.

▲

loeg 4 days ago | parent [-]

It's not just arbitrary renaming (Rust Result vs C++ Expected is fine) -- it's choosing a conflicting name for an extremely common abstract data type. If they wanted to call it "Elephant," great, but Optional is a well-known concept and Result/Expected isn't the same thing.

(I don't really object to the idea of skipping a real Optional<T> type in a language in favor of just Result<T, ()>.)

▲

jeremyjh 4 days ago | parent [-]

I would guess the two languages have little overlap in who they appeal to, and this is a bit closer to C semantics which is their north star. In C for functions that don’t return a value you often return a null for success or a return code that is a defined error code, which is exactly how Optional works in C3 (but you don’t write the word Optional in the function head). If you need to return a value in C you often pass an out param pointer and then still return either null or a defined error value. The improvement is you just write ‘type?’ for the return type to enable this and you don’t need an out param, but you still need the define (faultdef).

▲

fc417fc802 4 days ago | parent [-]

It's not about C semantics it's about the name of a commonly understood concept. What you just described there is the "result" pattern not the "optional" pattern. Of course the designers are free to call it whatever they want but swapping common terminology like that is a blunder from my perspective.

▲

jeremyjh 4 days ago | parent [-]

This is not exactly the same as the Result pattern. It doesn't require an ADT feature and does not require the programmer to specify a type for the possible error value.

Also syntactically it is quite different: it means you add exactly one character to the function head to denote that its possible to return an error.

So, calling that feature "Result" could also be confusing to people who have not yet learned this language.

Tell me, was it a blunder when Rust swapped "Result" from the commonly understood name of "Either" from OCaml/Haskell ?

	▲	fc417fc802 4 days ago \| parent [-]
		> It doesn't require an ADT feature and does not require the programmer to specify a type for the possible error value. I don't think that really matters? Result is "A or error" whereas optional is "A or nil". Admittedly my wording was sloppy. It's technically a subset of the pattern when taken literally. But there's a very strong convention for the error type in C so at least personally I don't find the restriction off putting. To me the issue is the name clash. This is most definitely not the "optional" pattern. I actually prefer C++'s "expected" over "result" as far as name clarity goes. "Maybe" would presumably also work. At the end of the day it's all a non-issue thanks to the syntax. I might not agree with what you expressed but I also realize a name that only shows up in the docs isn't going to pose a problem in practice. Probably more than half the languages out there confuse or otherwise subtly screw up remainder, modulus, and a few closely related mathematical concepts but that doesn't get in the way of doing things.