3 ms·

First-class tuples would make this code kind of unpleasant: func F() (A, B) { ... } func G(a A, b B) { ... } G(F()) Is the return value of F a tup

First-class tuples would make this code kind of unpleasant: func F() (A, B) { ... } func G(a A, b B) { ... } G(F()) Is the return value of F a tuple? Is the parameter list of G a tuple? Given H: func H(ab (A, B)) { ... } How and when is H(F()) different from G(F())? (Before you suggest a Python-like star operator, personally I consider using it for non-homogenous arguments about as hygienic as keeping your toothbrush and dirty socks in the same drawer.)

masklinn 3y ago
> First-class tuples would make this code kind of unpleasant: Which assumes this code matters much, outside of errors for which intermediate processors can just take... a tuple of a value and an error. Also assumes the magical splatting of MRVs is a good thing in the first place. > (Before you suggest a Python-like star operator, personally I consider using it for non-homogenous arguments about as hygienic as keeping your toothbrush and dirty socks in the same drawer.) That is literally what Go currently does for MRVs, except opt-in instead of magical. There is nothing about such splatting which wouldn't work with proper tuples, if anything it's the opposite. It is, essentially, the value side of `uncurry`.
- rollcat 3y ago
  I don't necessarily disagree, but it depends on your goals as a language designer. I think it's OK to sacrifice a niche feature for improved readability in the common case. Anonymous structs are not as fundamentally useful as e.g. anonymous functions. > Also assumes the magical splatting of MRVs is a good thing in the first place. IMHO, G(F()) reads nicer than some variant of G(*F()) or G(F()...). Lua does this too, and is (not unlike Go) considered a simple and elegant language. > Which assumes this code matters much, outside of errors for which intermediate processors can just take... a tuple of a value and an error. Then you'll sooner or later find yourself writing a G((a, b)), which again, I think is a net loss to readability. I think my argument would've been much stronger if Go had had generics in 1.0, and the stdlib/ecosystem wasn't already full of MustParse's and MustCompile's. But in that case we could've had a Result type as well.

masklinn 3y ago

> First-class tuples would make this code kind of unpleasant: Which assumes this code matters much, outside of errors for which intermediate processors can just take... a tuple of a value and an error. Also assumes the magical splatting of MRVs is a good thing in the first place. > (Before you suggest a Python-like star operator, personally I consider using it for non-homogenous arguments about as hygienic as keeping your toothbrush and dirty socks in the same drawer.) That is literally what Go currently does for MRVs, except opt-in instead of magical. There is nothing about such splatting which wouldn't work with proper tuples, if anything it's the opposite. It is, essentially, the value side of `uncurry`.

rollcat 3y ago
I don't necessarily disagree, but it depends on your goals as a language designer. I think it's OK to sacrifice a niche feature for improved readability in the common case. Anonymous structs are not as fundamentally useful as e.g. anonymous functions. > Also assumes the magical splatting of MRVs is a good thing in the first place. IMHO, G(F()) reads nicer than some variant of G(*F()) or G(F()...). Lua does this too, and is (not unlike Go) considered a simple and elegant language. > Which assumes this code matters much, outside of errors for which intermediate processors can just take... a tuple of a value and an error. Then you'll sooner or later find yourself writing a G((a, b)), which again, I think is a net loss to readability. I think my argument would've been much stronger if Go had had generics in 1.0, and the stdlib/ecosystem wasn't already full of MustParse's and MustCompile's. But in that case we could've had a Result type as well.