> C++ enums can't have methods, even C++ 11 scoped enums ("enum classes") can't have methods, I have no idea why that restriction seemed like a good idea

It is possible that Oracle holding the patent[1] to methods on enums is the blocker, rather than any technical restriction.

[1]: https://patents.google.com/patent/US7263687

That sounds bizarre. So this means that parents are potentially holding back programming language innovation? I hope I don’t have to consult with a lawyer every time I invent a new variation on the for loop. (I anticipate that someone will then tell me that there already is a patent for that…)

Why would it be bizarre? It's not exactly a fringe belief that patents in all software are holding back innovation.

I don't think programmers often consult 20 year old "inventions", so it seems pretty obvious on its face that the supposed benefit of patents, that something is _only_ locked up for 20 years, is quite pointless in software.

Anyway, for loops are safe, unless the for loop is over the elements of a linked list. Then you need to wait until next year: https://patents.google.com/patent/US7028023B2

Doesn't that patent's claims cover doubly-linked lists? The "auxilary order" could very well be reverse order. Seems like an obvious prior art.

I am absolutely not a lawyer, but wouldn’t it fall into the “trivial” category, so even if patented, it couldn’t be enforced?

Problem is, unless it has been tried in court, you can't be certain. And if you're building something, you might not want to spend time in court having to fight it in the first place. So even if it's 50/50 enforceable/not enforceable, do you really want to spend the time testing if it is?

Patents really have a chilling effect, even if a particular one might not be enforceable.

Also the ISO is also very averse of patents. They will probably not standardize anything patent-encumbered. They would probably require invalidating the patent first before accepting it in the standard.

Having said that this is the first time I ever heard of methods on enums being patented, what a ridiculous patent. It's a good thing then that C++ doesn't have methods, it has "member functions" :).

Also C++ allows user defined operators on enums, which feels somewhat adjacent.

WG21 (the "C++ Committee") is under JTC1 the Joint Technical Committee ("joint" between ISO and IEC), now, you might know of a few other famous products of the Joint Technical Committee's sub and sub-sub committees, including JPEG (that's the Joint Photographic Experts Group getting a shout out in the name of the standard) and MPEG. Those standards both required patented "inventions" to implement in full. The patents were held by contributors...

In the case of MPEG the result is MPEG LA, a US company which you need to pay to implement certain important standards. In the case of JPEG the result was a little different, since only the improved Arithmetic Coding of JPEG was patented, people just don't implement the actual standard, they cut out the patented part, so all the world's JPEGs (well, mostly JFIF files, which are slightly different but we call them "JPEGs" anyway) are a little bigger than they need to be for no reason except patents.

So no, I don't buy that "ISO is also very averse of patents" in a sense that would restrict this unless you can show that's a new stance.

Yeah, good point. But I think this still applies to WG21.

That expires in 2024, so perhaps the next version of C++ will have it.

I just wish that Rust’s enum Variants were types… maybe someday! :)

It's not exactly what you want but you get most of the benefit by just wrapping types in enum variants.

It's a request for the following to be valid

    enum X {
        A,
        B,
    }
    fn foo() -> X::A {
        X::A
    }

which helps a lot when composing state machines. In the meantime, you can indeed do what you propose:

    enum X {
        A(Foo),
        B(Bar),
    }
    struct Foo;
    struct Bar;
    fn foo() -> Foo {
        Foo
    }

Thanks yeah, I was just meaning for the ergonomics aspect :) Cheers

Since I've heard of this idea, I keep finding places where id use it, whether that be for variant-specific behavior or to remove the redudant type definitions in my API.