4 ms·

Then you can't construct it unless it's successful, no? A Result<T> that can only contain successful values doesn't seem very useful

joshuamorton 6y ago
No, you just are forced to use methods like foo.UnwrapOr(default_value) to get the Result. Or depending on the language, you get a compile error if you don't handle both possible values of the Result enum in a switch statement or if/else clause. See for example https://doc.rust-lang.org/std/result/enum.Result.html#method.unwrap_or_default https://doc.rust-lang.org/std/result/enum.Result.html#method... in rust, https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html#orElse-T- https://docs.oracle.com/javase/8/docs/api/java/util/Optional... in Java, and https://en.cppreference.com/w/cpp/utility/optional/value_or https://en.cppreference.com/w/cpp/utility/optional/value_or in C++.
- AaronFriel 6y ago
  Who are you replying to? Is any of your elaboration related to this result type? class Result<T> { bool IsSuccess {get; set;} string Message {get; set;} T Data {get; set;} }
  - joshuamorton 6y ago
    Ah you're quite correct.
grandmczeb 6y ago
Yes you can? The equivalent type in C++ is std::expected[1] which doesn't even contain a pointer that could be dereferenced (unless T is a pointer obviously). [1] unfortunately not standardized yet https://github.com/TartanLlama/expected https://github.com/TartanLlama/expected
- AaronFriel 6y ago
  Who are you replying to? Is it in any way related to the original comment I replied to and this type? class Result<T> { bool IsSuccess {get; set;} string Message {get; set;} T Data {get; set;} }
  - grandmczeb 6y ago
    I am replying to you and its pretty obviously related to your comment. You: "C++, Java, and so on have had generics for ages and with types like the one above, null pointer exceptions are incredibly common." jcelerier: "you'd never get a null-pointer exception in C++ given the type that OP mentioned." You: "Then you can't construct it unless it's successful, no?" Me: "The equivalent type in C++ [to what the OP mentioned] is std::expected". It is not possible to get a null-pointer exception with this type and yet you can construct it.
    - AaronFriel 6y ago
      It sounds quite a lot like you took the type the OP posted and changed it in your reply to a different type that isn't standardized yet, do I have that right?
      - grandmczeb 6y ago
        The code the OP posted is not C++. If you translate it to C++ there is no way to get a null pointer exception. It sounds quite a lot like you're looking to be pointlessly argumentative, do I have that right?
        AaronFriel 6y ago
        There are two things being discussed in this thread. 1. The first, my original point was that a high quality type system enforces correctness by more than just having generics. There's no proper way in C++ to create this class and make a sum type - there's no pattern matching or type narrowing like can be done in languages with more interesting type systems and language facilities. Generics is just a first step to a much more interesting, safer way of writing code. 2. The second, my replies to folks who have corrected me, and I'll borrow your little paraphrase here: > [Me]: "C++, Java, and so on have had generics for ages and with types like the one above, null pointer exceptions are incredibly common." > > jcelerier: "you'd never get a null-pointer exception in C++ given the type that OP mentioned." > > [Me]: "Then you can't construct it unless it's successful, no?" I think this is exactly correct still. If it's impossible to create an instance of Result<T> without... well, a successful result, you may as well just typedef Result<T> to T, right? If it can't store the "failure" case, it's totally uninteresting. If it _can_ store the failure case, making it safe in C++ is fairly challenging and I dare say it will be a little longer and a little less safe than a Result I can write in a few lines of TypeScript, Scala, Rust, an ML or Haskell derivative, and so on. Now, I'd love to be proven wrong, I haven't written C++ for a while so the standard may have changed, but is there a way to write a proper enum and pattern match on the value? It looks like this std::expected thing is neat, but can a _regular person_ write it in their own code and expect it to be safe? I can say with certainty that I can do that for the languages I listed above and in fewer than 10 lines of code. The C++ answer to that is, well, this: https://github.com/TartanLlama/expected/blob/master/include/tl/expected.hpp https://github.com/TartanLlama/expected/blob/master/include/... I don't think it's a comparison.

joshuamorton 6y ago

No, you just are forced to use methods like foo.UnwrapOr(default_value) to get the Result. Or depending on the language, you get a compile error if you don't handle both possible values of the Result enum in a switch statement or if/else clause. See for example https://doc.rust-lang.org/std/result/enum.Result.html#method.unwrap_or_default https://doc.rust-lang.org/std/result/enum.Result.html#method... in rust, https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html#orElse-T- https://docs.oracle.com/javase/8/docs/api/java/util/Optional... in Java, and https://en.cppreference.com/w/cpp/utility/optional/value_or https://en.cppreference.com/w/cpp/utility/optional/value_or in C++.

AaronFriel 6y ago
Who are you replying to? Is any of your elaboration related to this result type? class Result<T> { bool IsSuccess {get; set;} string Message {get; set;} T Data {get; set;} }
- joshuamorton 6y ago
  Ah you're quite correct.

grandmczeb 6y ago

Yes you can? The equivalent type in C++ is std::expected[1] which doesn't even contain a pointer that could be dereferenced (unless T is a pointer obviously). [1] unfortunately not standardized yet https://github.com/TartanLlama/expected https://github.com/TartanLlama/expected

AaronFriel 6y ago
Who are you replying to? Is it in any way related to the original comment I replied to and this type? class Result<T> { bool IsSuccess {get; set;} string Message {get; set;} T Data {get; set;} }
- grandmczeb 6y ago
  I am replying to you and its pretty obviously related to your comment. You: "C++, Java, and so on have had generics for ages and with types like the one above, null pointer exceptions are incredibly common." jcelerier: "you'd never get a null-pointer exception in C++ given the type that OP mentioned." You: "Then you can't construct it unless it's successful, no?" Me: "The equivalent type in C++ [to what the OP mentioned] is std::expected". It is not possible to get a null-pointer exception with this type and yet you can construct it.
  - AaronFriel 6y ago
    It sounds quite a lot like you took the type the OP posted and changed it in your reply to a different type that isn't standardized yet, do I have that right?
    - grandmczeb 6y ago
      The code the OP posted is not C++. If you translate it to C++ there is no way to get a null pointer exception. It sounds quite a lot like you're looking to be pointlessly argumentative, do I have that right?
      - AaronFriel 6y ago
        There are two things being discussed in this thread. 1. The first, my original point was that a high quality type system enforces correctness by more than just having generics. There's no proper way in C++ to create this class and make a sum type - there's no pattern matching or type narrowing like can be done in languages with more interesting type systems and language facilities. Generics is just a first step to a much more interesting, safer way of writing code. 2. The second, my replies to folks who have corrected me, and I'll borrow your little paraphrase here: > [Me]: "C++, Java, and so on have had generics for ages and with types like the one above, null pointer exceptions are incredibly common." > > jcelerier: "you'd never get a null-pointer exception in C++ given the type that OP mentioned." > > [Me]: "Then you can't construct it unless it's successful, no?" I think this is exactly correct still. If it's impossible to create an instance of Result<T> without... well, a successful result, you may as well just typedef Result<T> to T, right? If it can't store the "failure" case, it's totally uninteresting. If it _can_ store the failure case, making it safe in C++ is fairly challenging and I dare say it will be a little longer and a little less safe than a Result I can write in a few lines of TypeScript, Scala, Rust, an ML or Haskell derivative, and so on. Now, I'd love to be proven wrong, I haven't written C++ for a while so the standard may have changed, but is there a way to write a proper enum and pattern match on the value? It looks like this std::expected thing is neat, but can a _regular person_ write it in their own code and expect it to be safe? I can say with certainty that I can do that for the languages I listed above and in fewer than 10 lines of code. The C++ answer to that is, well, this: https://github.com/TartanLlama/expected/blob/master/include/tl/expected.hpp https://github.com/TartanLlama/expected/blob/master/include/... I don't think it's a comparison.