4 ms·

> It's disappointing that the committee chose only to solve this problem while not also solving the problem of forgetting to check for null -- often called "the

> It's disappointing that the committee chose only to solve this problem while not also solving the problem of forgetting to check for null -- often called "the billion-dollar mistake". it's likely ~30 loc to wrap std::optional in your own type that checks for null. if std::optional checked for null and these `if` branch showed up as taking the couple nanoseconds that make you go past your time budget in your real-time system (especially if people were doing things like if(b) { foo(b); bar(b); baz(*b); }) then you have to reimplement the whole of it instead. Don't forget that you can still use C++ on 8mhz microcontrollers.

monocasa 6y ago
The ideal situation is then to not use std::optional for those cases rather than to make std::optional next to useless for it's stated case. If it gets in the way of your goal on an 8Mhz controller, take the optionality check out of your tight loop and convert to a null pointer safely where it doesn't matter. Deeply embedded is already used to picking and choosing features, or explicitly running with the bumper rails off in the subset of cases where it matters. We like the normal primitives not being neutered for us because we still use a lot of them outside of our tight loops.
- CyberRabbi 6y ago
  > than to make std::optional next to useless for it's stated case. This is such a ridiculous and obviously false assertion that it’s indistinguishable from satire. Optional is widely used and was modeled from a pre-existing boost class which was itself widely used. Do you actually write C++ professionally?
  - monocasa 6y ago
    Yes. And I think (hope?) that std::optional is going to make it's way into the dust bins of history like auto_ptr. When the answer is "just don't deference it if it's null", then why not just use a pointer in the first place?
    - CyberRabbi 6y ago
      Again, optional is different from pointer because it offers value semantics.
      - monocasa 6y ago
        I know they're different (and the construct unfortunately named optional has some occasional uses); it's just that the semantics of optional don't help it be used as a classic optional type.
        jcelerier 6y ago
        > it's just that the semantics of optional don't help it be used as a classic optional type. what do you mean "classic optional type"? boost.optional has worked like that for something like 20 years - it's been in C++ for longer than Maybe has been in Haskell.
        monocasa 6y ago
        It's been in Standard ML since the 80s.
        tome 6y ago
        > it's been in C++ for longer than Maybe has been in Haskell. Tangentially, how did you conclude that? Haskell has around since 1990 but boost only since 1999, as far as I can tell. https://en.wikipedia.org/wiki/Haskell_(programming_language) https://en.wikipedia.org/wiki/Haskell_(programming_language) https://en.wikipedia.org/wiki/Boost_(C%2B%2B_libraries) https://en.wikipedia.org/wiki/Boost_(C%2B%2B_libraries)
kentonv 6y ago
Again, I'm not arguing that operator* should check for nullness, I'm arguing that it shouldn't exist. With `kj::Maybe` and `KJ_IF_MAYBE`, using the syntax I demonstrated above, you check for nullness once and as a result of the check you get a direct pointer to the underlying value (if it is non-null), which you then use for subsequent access, so you don't end up repeating the check. So, you get the best of both worlds. > it's likely ~30 loc to wrap std::optional It's even easier to replace std::optional rather than wrap it. The value of std::optional is that it's a standard that one would hope would be used across libraries. But because it's flawed, people like me end up writing their own instead.
- jcelerier 6y ago
  > So, you get the best of both worlds. I would really not call code that looks like this "best of both worlds" KJ_IF_MAYBE(value, maybeValue) { use(value); } else { handleNull(); } when compared to if(!value) handleNull(); use(*value);
  - kentonv 6y ago
    Kind of unfair that you didn't include the `else` or the braces in your version, just to make it look shorter.

monocasa 6y ago

The ideal situation is then to not use std::optional for those cases rather than to make std::optional next to useless for it's stated case. If it gets in the way of your goal on an 8Mhz controller, take the optionality check out of your tight loop and convert to a null pointer safely where it doesn't matter. Deeply embedded is already used to picking and choosing features, or explicitly running with the bumper rails off in the subset of cases where it matters. We like the normal primitives not being neutered for us because we still use a lot of them outside of our tight loops.

CyberRabbi 6y ago
> than to make std::optional next to useless for it's stated case. This is such a ridiculous and obviously false assertion that it’s indistinguishable from satire. Optional is widely used and was modeled from a pre-existing boost class which was itself widely used. Do you actually write C++ professionally?
- monocasa 6y ago
  Yes. And I think (hope?) that std::optional is going to make it's way into the dust bins of history like auto_ptr. When the answer is "just don't deference it if it's null", then why not just use a pointer in the first place?
  - CyberRabbi 6y ago
    Again, optional is different from pointer because it offers value semantics.
    - monocasa 6y ago
      I know they're different (and the construct unfortunately named optional has some occasional uses); it's just that the semantics of optional don't help it be used as a classic optional type.
      - jcelerier 6y ago
        > it's just that the semantics of optional don't help it be used as a classic optional type. what do you mean "classic optional type"? boost.optional has worked like that for something like 20 years - it's been in C++ for longer than Maybe has been in Haskell.
        monocasa 6y ago
        It's been in Standard ML since the 80s.
        tome 6y ago
        > it's been in C++ for longer than Maybe has been in Haskell. Tangentially, how did you conclude that? Haskell has around since 1990 but boost only since 1999, as far as I can tell. https://en.wikipedia.org/wiki/Haskell_(programming_language) https://en.wikipedia.org/wiki/Haskell_(programming_language) https://en.wikipedia.org/wiki/Boost_(C%2B%2B_libraries) https://en.wikipedia.org/wiki/Boost_(C%2B%2B_libraries)

kentonv 6y ago

Again, I'm not arguing that operator* should check for nullness, I'm arguing that it shouldn't exist. With `kj::Maybe` and `KJ_IF_MAYBE`, using the syntax I demonstrated above, you check for nullness once and as a result of the check you get a direct pointer to the underlying value (if it is non-null), which you then use for subsequent access, so you don't end up repeating the check. So, you get the best of both worlds. > it's likely ~30 loc to wrap std::optional It's even easier to replace std::optional rather than wrap it. The value of std::optional is that it's a standard that one would hope would be used across libraries. But because it's flawed, people like me end up writing their own instead.

jcelerier 6y ago
> So, you get the best of both worlds. I would really not call code that looks like this "best of both worlds" KJ_IF_MAYBE(value, maybeValue) { use(value); } else { handleNull(); } when compared to if(!value) handleNull(); use(*value);
- kentonv 6y ago
  Kind of unfair that you didn't include the `else` or the braces in your version, just to make it look shorter.