std::in_place_stop_source::get_token and std::get_stop_token const correctness

[jtsylve]

In the current proposal, in_place_stop_source::get_token is const qualified, and std::get_stop_token requires a const parameter.

The problem in practice is that token callbacks almost certainly need to register themselves with the source, which tends to require that the token maintain a pointer or reference to the source. With get_token being const qualified, the source can only pass a constant reference or pointer to itself to be stored by the token, but the callback almost certainly needs to mutate the source to register itself.

libunifex doesn't have this issue because their implementation of get_token is not const qualified.
stdexec follows the specification and had to resort to marking its list of callbacks as mutable, which is usually considered a code smell by many.

I am curious about the reasoning behind this decision. I know that std::stop_source made the same choice, but those implementations do not require callback registration.

[ericniebler]

This is a good question for @lewissbaker