4 ms·

> They're already a special type to an extent This is news to me. How so? > since Go's MRV are not first-class it could add builtin facilities applicable to a

> They're already a special type to an extent This is news to me. How so? > since Go's MRV are not first-class it could add builtin facilities applicable to any 1..n-ary return value whose last value is either an Error or an Error-implementing struct or somesuch. MRV is "first-class" for the purposes of this discussion. Your proposal still depends on treating `error` as a special type, so my criticisms still apply--the juice just isn't worth the squeeze. That said, if another mechanism is introduced (for example, a trait-like system for hanging sugar off of a la Rust's), then the calculus changes; however, as previously mentioned, error handling sugar is not a good reason to add such a system.

masklinn 8y ago
> MRV is "first-class" for the purposes of this discussion. MRV is not first-class for any purpose. > Your proposal still depends on treating `error` as a special type, so my criticisms still apply--the juice just isn't worth the squeeze. That said, if another mechanism is introduced 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. 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. > for example, a trait-like system for hanging sugar off of a la Rust's 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. [0] the Try trait aims to eventually allow its use beyond these, but is currently nightly-only
- weberc2 8y ago
  > 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

> MRV is "first-class" for the purposes of this discussion. MRV is not first-class for any purpose. > Your proposal still depends on treating `error` as a special type, so my criticisms still apply--the juice just isn't worth the squeeze. That said, if another mechanism is introduced 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. 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. > for example, a trait-like system for hanging sugar off of a la Rust's 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. [0] the Try trait aims to eventually allow its use beyond these, but is currently nightly-only

weberc2 8y ago
> 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.