3 ms·

> Languages also need to be: > * Easy to read The motivating examples of this whole proposal are examples where one reads the code and the semantics are uncle

by amluto 4y ago

> Languages also need to be: > * Easy to read The motivating examples of this whole proposal are examples where one reads the code and the semantics are unclear. > PPS: If you think multiple returns and sumtypes solve the same thing, you've not thought very hard on the subject... The stereotypical example of multiple returns in Go is functions that return val, err when they mean that they return one of a value or an error. Which is what sum types do.

josephcsible 4y ago
> The stereotypical example of multiple returns in Go is functions that return val, err when they mean that they return one of a value or an error. Which is what sum types do. The point is that with real sum types, the compiler will enforce that you return exactly one of a value or an error, whereas in Go, you're just supposed to do so, and it's possible to write code that mistakenly returns both or neither.
zbobet2012 4y ago
Yeah, but multiple returns are _used for other things_. So they encompass error returns _and other things_. Multiple returns by the way would be product types that are being automatically unpacked. One of Go's core missions is to keep the number of concepts users need low. Multiple returns encompass the error use case and others.
- amluto 4y ago
  Sure, and everything people do with sum types can also be done with plain C structs, and has been done like that in decades. But I think that saying that multiple returns (which are a sort of product type) “encompass” the error use case (logically a sum type) is overstating the case a bit. I would accept that returning errors can be achieved without sum types (and obviously is achieved without sum types in practice in the huge amount of code in languages that don’t have sum types). But I would not personally design a new language without sum types or some other similarly strict solution for the kind of programming that will encounter errors.

by amluto 4y ago

josephcsible 4y ago

> The stereotypical example of multiple returns in Go is functions that return val, err when they mean that they return one of a value or an error. Which is what sum types do. The point is that with real sum types, the compiler will enforce that you return exactly one of a value or an error, whereas in Go, you're just supposed to do so, and it's possible to write code that mistakenly returns both or neither.

zbobet2012 4y ago

Yeah, but multiple returns are _used for other things_. So they encompass error returns _and other things_. Multiple returns by the way would be product types that are being automatically unpacked. One of Go's core missions is to keep the number of concepts users need low. Multiple returns encompass the error use case and others.

amluto 4y ago
Sure, and everything people do with sum types can also be done with plain C structs, and has been done like that in decades. But I think that saying that multiple returns (which are a sort of product type) “encompass” the error use case (logically a sum type) is overstating the case a bit. I would accept that returning errors can be achieved without sum types (and obviously is achieved without sum types in practice in the huge amount of code in languages that don’t have sum types). But I would not personally design a new language without sum types or some other similarly strict solution for the kind of programming that will encounter errors.