Date: Mon, 4 Apr 2022 10:25:37 +0200
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_at_[hidden]> 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_at_[hidden]> 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_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
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_at_[hidden]> 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_at_[hidden]> 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_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2022-04-04 08:25:50