4 ms·

> MRV is not first-class for any purpose. You're going to have to elaborate because MRV as it exists today is sufficient for your proposal. If you mean "you're

> MRV is not first-class for any purpose. You're going to have to elaborate because MRV as it exists today is sufficient for your proposal. If you mean "you're returning something that looks like a tuple, but you can't use it like a tuple" then that's all true but I don't see how that's necessary to implement your propsal. > There is no need for "an other mechanism" since as you yourself note the only need is for the compiler to understand the existence of error, which would require no change to userland code or break any existing. I agree that this is true, but I disagree that it's advisable to make `error` a special type to the compiler. > Hell, technically and if you want a lowest denominator that isn't even necessary, you can hang it off of the MRV itself (which is very much a built-in special-purpose not-first-class construct) and have syntactic sugar for special-handling of the last return value, irrespective of its actual type. Sure, but still a bad idea. > try! and ? don't "hang off of" a trait, they work specifically on `Result`[0]. They only use traits for the sub-feature of automatic conversion of the error value, which IME is only a small and non-necessary part of the feature: usually you either return the error as-is or need to add context beyond what can be extracted from the original. I was referring to the Try trait, but as you mention, it's only available on nightly. Nevertheless, I object to making the error type special to the compiler for the negligible advantage of eliding some boilerplate. If this is facilitated by some more general mechanism (e.g., monads or the Try trait), then so be it. Do note that this is my opinion, and you're free to disagree with it.

masklinn 8y ago
> You're going to have to elaborate because MRV as it exists today is sufficient for your proposal. If you mean "you're returning something that looks like a tuple, but you can't use it like a tuple" then that's all true but I don't see how that's necessary to implement your propsal. First-class features can be manipulated as regular values of the language. 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. > I was referring to the Try trait, but as you mention, it's only available on nightly. 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 ?.
- weberc2 8y ago
  > 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.
  - steveklabnik 8y ago
    FWIW, part of why Try has taken a really long time to stabilize is that there's not a ton of pressure, having it for Result was about 80% of the power, Option about 10% more.

masklinn 8y ago

> You're going to have to elaborate because MRV as it exists today is sufficient for your proposal. If you mean "you're returning something that looks like a tuple, but you can't use it like a tuple" then that's all true but I don't see how that's necessary to implement your propsal. First-class features can be manipulated as regular values of the language. 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. > I was referring to the Try trait, but as you mention, it's only available on nightly. 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 ?.

weberc2 8y ago
> 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.
- steveklabnik 8y ago
  FWIW, part of why Try has taken a really long time to stabilize is that there's not a ton of pressure, having it for Result was about 80% of the power, Option about 10% more.