> That Go's MRV are not first-class are an advantage with respect to my proposal: they're already a "magical" built-in which can't be manipulated from within go

> That Go's MRV are not first-class are an advantage with respect to my proposal: they're already a "magical" built-in which can't be manipulated from within go. As a result, new features built on MRV can't conflict with existing manipulations of MRV. That's still irrelevant to your sugar proposal; even if they were properly tuples (tuples are the proper term for "first class MRV" per your definition), the _type_ of the tuple (e.g., `(int, int, error)`) would be the thing you would base your sugar off of, not the actual value. > And a very recent addition: `try!` does not use it and I've not seen any plan to retrofit it. Try is a way to extend ? to non-Result structures. ? is not built upon Try, Try is being extracted from ?. Cool, but that doesn't change the calculus for Go. Hard-coding sugar to a specific type remains a bad idea.