Using exceptions in C++ desktop and server applications overall made sense to me. As I expanded my usage of C++ into other domains, specifically embedded domains, I began to experience more compelling reasons not to use exceptions first-hand…

From lobste.rs

  • lysdexic
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    4
    ·
    1 year ago

    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.

    • marcos@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      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.

      • qwertyasdef
        link
        fedilink
        arrow-up
        3
        ·
        1 year ago

        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.

    • BatmanAoD
      link
      fedilink
      arrow-up
      3
      arrow-down
      1
      ·
      1 year ago

      You seem to be ignoring the benefits of compiler support as mentioned in the comment above.

      • lysdexic
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        1 year ago

        compiler support

        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.

        • BatmanAoD
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          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.

          • lysdexic
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            1 year ago

            Unless I’m misreading, you brought monads into it.

            You’re misreading it. What do you think a ‘Result’ type is?

            • BatmanAoD
              link
              fedilink
              arrow-up
              1
              ·
              1 year ago

              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.

              • lysdexic
                link
                fedilink
                English
                arrow-up
                1
                ·
                edit-2
                1 year ago

                Well, in Rust, it’s a sum-type

                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++.

                • BatmanAoD
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  1 year ago

                  The discussion was about sum types. The top-level comment, the one to which you originally responded, says:

                  It’s a shame that sum type support is still so lacking in C++. Proper Result types (ala Haskell or Rust) are generally much nicer to deal with, especially in embedded contexts.