Re:Expectations for generics in Go 1.18
by Zababa on Thursday October 28, 2021 @07:20AM
(#29024719)
Don't you need sum types/sufficiently powerful enums for Result though? Which, in a way, makes it a language feature.
[ Parent
| on HN ]
Re:Expectations for generics in Go 1.18
by masklinn on Thursday October 28, 2021 @09:22AM
(#29025801)
You’re confusing the chicken for the egg.
Sum types are a powerful language feature, but they’re also a general language feature, they don’t exist for the sole purpose of creating a Result type (and indeed a number of languages have had the former and lacked the latter).
I still don't get what's wrong with having custom syntax or language facilities to support a feature. Why is that a problem?
Do you mean that in contrast to affine types, that are here for borrow checking?
Re:Expectations for generics in Go 1.18
by masklinn on Saturday October 30, 2021 @02:40PM
(#29051238)
No, I mean that in contrast to the other side of the discussion (zig’s errors).
And affine types are not here for borrow checking, it’s closer to the opposite. Affine types are a formalisation of RAII, borrow checking is a way to make references memory-safe without runtime overhead which mostly avoids unnecessary (and sometimes impossible requiring allocations & refcounting) copies of affine types.