3 ms·

> - abstract data types I suppose you meant to say "algebraic data types"? (which have been adopted by Rust and Swift, and even the C++ stdlib)

lmm 7y ago
C++ doesn't actually have ADTs. std::variant is not a true sum type (1 + 1 + 2 = 3, so to speak).
- mwcampbell 7y ago
  Can you please explain further why std::variant is not a true sum type?
  - lmm 7y ago
    If you form a variant with multiple copies of the same type they will "collapse". E.g. std::variant<int, int> behaves like std::variant<int>.
    - mwcampbell 7y ago
      Why would you want to list int more than once in a variant? I must be missing a use case here; my variants have consisted mostly of structs.
      - lmm 7y ago
        It's less that you specifically want an int/int case and more that you want consistent behaviour in a generic context - you might have some logic in a template that uses variant<int, T> and treats the int case specially (e.g. the int is an error code), but then you get a nasty surprise when it gets used in a case where T=int. A common example is validation/result types, which often look like string (error message) or valid result. So e.g. you might have a username validator that returns Result<String, String> and then various other user creation validation things that return e.g. Result<String, EmailAddress> and in the end you compose them all together to get Result<String, User>. That's a very powerful style that has the advantages of exceptions (the "happy path" through the code is obvious and not obscured by all the failure handling) without their disadvantages ("magic" control flow, seemingly trivial refactors changing the behaviour). But it's less practical if you can't have Result<String, String> at the base level.
hardwaresofton 7y ago
Yes definitely, I meant ADTs and GADTS -- Algebraic Data Types They're a super good idea, so I'm glad that other languages are adopting it, but this is the kind of thing that haskell has had for a long time and is just second nature.

lmm 7y ago

C++ doesn't actually have ADTs. std::variant is not a true sum type (1 + 1 + 2 = 3, so to speak).

mwcampbell 7y ago
Can you please explain further why std::variant is not a true sum type?
- lmm 7y ago
  If you form a variant with multiple copies of the same type they will "collapse". E.g. std::variant<int, int> behaves like std::variant<int>.
  - mwcampbell 7y ago
    Why would you want to list int more than once in a variant? I must be missing a use case here; my variants have consisted mostly of structs.
    - lmm 7y ago
      It's less that you specifically want an int/int case and more that you want consistent behaviour in a generic context - you might have some logic in a template that uses variant<int, T> and treats the int case specially (e.g. the int is an error code), but then you get a nasty surprise when it gets used in a case where T=int. A common example is validation/result types, which often look like string (error message) or valid result. So e.g. you might have a username validator that returns Result<String, String> and then various other user creation validation things that return e.g. Result<String, EmailAddress> and in the end you compose them all together to get Result<String, User>. That's a very powerful style that has the advantages of exceptions (the "happy path" through the code is obvious and not obscured by all the failure handling) without their disadvantages ("magic" control flow, seemingly trivial refactors changing the behaviour). But it's less practical if you can't have Result<String, String> at the base level.

hardwaresofton 7y ago

Yes definitely, I meant ADTs and GADTS -- Algebraic Data Types They're a super good idea, so I'm glad that other languages are adopting it, but this is the kind of thing that haskell has had for a long time and is just second nature.