I do not see the use-case, as it easily can be implemented with wrapper class/struct and operator():

struct S  {

    enum E  {
        VALUE_1,
        VALUE_2
    };

    E value_;

    S operator()(int state, double value) {
        switch (value_) {
            case E::VALUE_1 : {
                std::cout << "VALUE_1 int:" << state << " dbl:" << value << std::endl;
                return S{E::VALUE_2};
            }
            case E::VALUE_2 : {
                std::cout << "VALUE_1 int:" << state << " dbl:" << value << std::endl;
                return S{E::VALUE_1};
            }
            default: throw std::domain_error("Undefined value");
        }
    }

};




int main() {
    S state{S::VALUE_1};


    state = state(1, 3.14);
    state = state(2, 10.0);

    // Additional syntax sugar
    state = state
        (1, 3.14)
        (2, 10);

}

On Fri, Apr 1, 2022 at 7:04 PM Gergely Nagy via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

Hi,

Well, state machines are not that uncommon. The self-mutating part is not much weirder than the self-mutating nature of a normal class.

Besides state machines, it can be useful for VM-like things.

The point is that maintaining switch statements together with the enum is error-prone above a level.

If "out-of-the-box" self-mutation is a problem, it can be made an opt-in feature, like for lambdas:

enum class DispatchStuff(int Arg1, double Arg2) mutable : int {

Of course there are nuances, like can it be templated for the arguments, etc...

Thanks,
Gergely

Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org> ezt írta (időpont: 2022. ápr. 1., P, 18:53):
Is this a circumstance that comes up often enough to *require* a
language feature like this? I mean yes, it simplifies these specific
cases, but are these cases prevalent enough to be worthy of being
simplified?

I would much rather see the code spelled out, so that it is pretty
obvious what is going on when you "call" such a value. Especially if
it's going to be self-mutating.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals