4 ms·

This sounds like an invitation for logic bugs and corruption. > It’s better than option primarily because it means a lot less code. Option doesn't need any ex

This sounds like an invitation for logic bugs and corruption. > It’s better than option primarily because it means a lot less code. Option doesn't need any extra code for checking the presence of a value when it's done right. In Rust, you just place a ? sigil at the end of the option expression. In Haskell, you just use the do syntax where val <- optional will assign the value to `val` if `optional` is some value rather that none, and it will exit the do block otherwise.

CraigJPerry 4y ago
>> Option doesn't need any extra code Ahh, those are both logic errors in your code. You do need the extra code to fix your errors here: >> In Rust, you just place a ? sigil at the end That changes the behaviour to bubble up that there was no value, the caller has been delegated responsibility and further processing has stopped at this point. Instead to accurately implement the required behaviour and replicate the nil punning logic, you’d need ? to behave in such a way that it inserts a suitable “empty” value for whatever type the option is guarding. So if this was an optional collection for example, the ? would need to figure out what type of collection then how to get an empty one to provide here (and you’d probably want that to be a singleton immutable collection, otherwise you’d be risking introducing logic bugs). In practice, you’d instead write code to provide that empty collection at the call site. At this point you’ve rendered the Option wrapper pointless though. It’s the exact same story for your Haskell example. You’ve given a different behaviour which is of course, a logic bug.
- feanaro 4y ago
  > to behave in such a way that it inserts a suitable “empty” value for whatever type the option is guarding. Some types have no suitable "empty" value. It is dangerous to assume you can always find such a value. In essence, when you're expecting that such a value exists, you're implicitly relying on your type being a suitable monoid. That's fine when you're expecting this and when it is actually a monoid, but not all types are. > In practice, you’d instead write code to provide that empty collection at the call site. Not all types can be modelled as collections. This is the same problem as above. What I'd actually do is either: 1. Fail the parent operation by again using `?`, or 2. Provide a suitable default/"empty" type, if it is possible to continue. It's very important that such a decision is explicit on a case-by-case basis, and this is what `?` allows you to easily do without much fluff or noise. > At this point you’ve rendered the Option wrapper pointless though. How was it useless? It allowed us to safely write a procedure as if the value existed and otherwise cheaply signal failure to the caller. The caller can then repeat the same process. What's important is that the procedure stands on its own and is safe out of the box. It clearly says that it can fail (by returning an option) and we know exactly when it has failed and when it has not. > You’ve given a different behaviour which is of course, a logic bug. I don't see where the bug is?
  - CraigJPerry 4y ago
    >> I don't see where the bug is? That appears to be a willful decision on your part i think :-) A'dieu and all the best
    - feanaro 4y ago
      I was trying to be deliberately obtuse, it was a good faith question. I guess I just misunderstood what you were trying to say then. But no hard feelings and all the best to you too.
      - feanaro 4y ago
        *wasn't :D Yes, yes, cue the Freudian jokes.
    - Dylan16807 4y ago
      You are acting wrong here, fyi.
  - nybble41 4y ago
    > Some types have no suitable "empty" value. It is dangerous to assume you can always find such a value. Indeed. In Rust you have Option::unwrap_or_default() for this, which is only available if the underlying type implements the Default trait. It's unfortunately more verbose than `?` but it gives the behavior the GP wants, without making unsafe assumptions like 0 always being a safe default for any integer result.

CraigJPerry 4y ago

>> Option doesn't need any extra code Ahh, those are both logic errors in your code. You do need the extra code to fix your errors here: >> In Rust, you just place a ? sigil at the end That changes the behaviour to bubble up that there was no value, the caller has been delegated responsibility and further processing has stopped at this point. Instead to accurately implement the required behaviour and replicate the nil punning logic, you’d need ? to behave in such a way that it inserts a suitable “empty” value for whatever type the option is guarding. So if this was an optional collection for example, the ? would need to figure out what type of collection then how to get an empty one to provide here (and you’d probably want that to be a singleton immutable collection, otherwise you’d be risking introducing logic bugs). In practice, you’d instead write code to provide that empty collection at the call site. At this point you’ve rendered the Option wrapper pointless though. It’s the exact same story for your Haskell example. You’ve given a different behaviour which is of course, a logic bug.

feanaro 4y ago
> to behave in such a way that it inserts a suitable “empty” value for whatever type the option is guarding. Some types have no suitable "empty" value. It is dangerous to assume you can always find such a value. In essence, when you're expecting that such a value exists, you're implicitly relying on your type being a suitable monoid. That's fine when you're expecting this and when it is actually a monoid, but not all types are. > In practice, you’d instead write code to provide that empty collection at the call site. Not all types can be modelled as collections. This is the same problem as above. What I'd actually do is either: 1. Fail the parent operation by again using `?`, or 2. Provide a suitable default/"empty" type, if it is possible to continue. It's very important that such a decision is explicit on a case-by-case basis, and this is what `?` allows you to easily do without much fluff or noise. > At this point you’ve rendered the Option wrapper pointless though. How was it useless? It allowed us to safely write a procedure as if the value existed and otherwise cheaply signal failure to the caller. The caller can then repeat the same process. What's important is that the procedure stands on its own and is safe out of the box. It clearly says that it can fail (by returning an option) and we know exactly when it has failed and when it has not. > You’ve given a different behaviour which is of course, a logic bug. I don't see where the bug is?
- CraigJPerry 4y ago
  >> I don't see where the bug is? That appears to be a willful decision on your part i think :-) A'dieu and all the best
  - feanaro 4y ago
    I was trying to be deliberately obtuse, it was a good faith question. I guess I just misunderstood what you were trying to say then. But no hard feelings and all the best to you too.
    - feanaro 4y ago
      *wasn't :D Yes, yes, cue the Freudian jokes.
  - Dylan16807 4y ago
    You are acting wrong here, fyi.
- nybble41 4y ago
  > Some types have no suitable "empty" value. It is dangerous to assume you can always find such a value. Indeed. In Rust you have Option::unwrap_or_default() for this, which is only available if the underlying type implements the Default trait. It's unfortunately more verbose than `?` but it gives the behavior the GP wants, without making unsafe assumptions like 0 always being a safe default for any integer result.