this post was submitted on 19 Aug 2023
37 points (87.8% liked)
Programming
17489 readers
83 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I would consider language support essential for "good" sum types. AFAIK, stuff like exhaustive pattern matching can't be accomplished by a library. Perhaps you could do some cursed stuff with compiler plugins, however.
(There was a library that implemented non-exhaustive pattern matching that eventually morphed into an ISO C++ proposal... so we won't see it until 2030 at the earliest /hj)
At a library level, couldn't you have an opaque sum type where the only thing you can do with it is call a
matchmethod that requires a function pointer for each possible variant of the sum type? It'd be pretty cursed to use but at least it wouldn't require compiler plugins.I'd bet five bucks some desperate Haskeller or Rustacean has implemented exactly that. You could also probably use nested functions for GCC C or lambdas in C++ to move everything inline?
I think that pattern matching and sum types are orthogonal to monads, and aren't really relevant when discussing monads as alternatives to exceptions. C++ didn't required any of those to add std::optional or std::variant, and those are already used as result monads.
Supporting Result and Either monads in the standard would be nice, but again this does not stop anyone from adopting one of the many libraries that already provide those.
Well, if you create result types without monads, you get go.
I would say it's completely essential, but you can do with some limited implementation of them.
I guess it depends on what you mean by using monads, but you can have a monadic result type without introducing a concrete monad abstraction that it implements.
You seem to be ignoring the benefits of compiler support as mentioned in the comment above.
That remark was on sum types, not monads. You do not need "compiler support" to have Result or neither monads in C++. There are already plenty of libraries that implement those. I use them in some of my projects. No compiler support needed.
As I said, sum types are not required for Return or Either monads. At best, they are convenient.
The original claim wasn't that you can't implement monads in C++, it was that compiler support is needed for "good" sum types. Unless I'm misreading, you brought monads into it. And they're not totally orthogonal: sum types are a very good way to implement monads.
You're misreading it. What do you think a '
Result' type is?Well, in Rust, it's a sum-type, with functions that also let you use it like a monad instead of using explicit pattern matching.
The discussion is on to use monads in C++, and not on why is C++ different than Rust.
I repeat: you do not need sum types to implement a Result monad in C++.
The discussion was about sum types. The top-level comment, the one to which you originally responded, says: