The `stoppable-source` concept doesn't permit some kinds of stop-source data-structures

[lewissbaker]

I have been working on a new stoppable_token data-structure that has a single stop-source/stop-state but that can have N independent stop-tokens, each of which can have at most one stop-callback associated with it at a time.

For example: Something along the following lines.

template<std::size_t N, std::size_t Idx, typename CB>
class finite_inplace_stop_callback;

template<std::size_t N, std::size_t Idx>
class finite_inplace_stop_token {
public:
  template<typename CB>
  using callback_type = finite_inplace_stop_callback<N, Idx, CB>;

  finite_inplace_stop_token() noexcept;
  finite_inplace_stop_token(const finite_inplace_stop_token&) = default;
  bool stop_requested() const noexcept;
  bool stop_possible() const noexcept;
};

template<std::size_t N, std::size_t Idx, typename CB>
class finite_inplace_stop_callback {
public:
  template<typename Init>
  requires std::constructible_from<CB, Init>
  finite_inplace_stop_callback(finite_inplace_stop_token<N, Idx> st, Init&& cb);
  ~finite_inplace_stop_callback();
};

template<std::size_t N>
class finite_inplace_stop_source {
public:
  finite_inplace_stop_source() noexcept;

  bool stop_possible() const noexcept;
  bool stop_requested() const noexcept;
  bool request_stop() noexcept;

  template<std::size_t Idx>
  requires (Idx < N)
  finite_inplace_stop_token<N, Idx> get_token() const noexcept;
};

The trouble is, this stop-source type has a get_token<Idx>() method to obtain a particular token, whereas the stoppable-source concept currently requires a get_token() member-function. Therefore this type would be unable to satisfy the stoppable-source concept and so could not benefit from the generic wording there.

Would it be possible to weaken the stoppable-source concept so that it does not specify how to get a stoppable_token from the stop-source, and just provided the other three methods? Then the relevant concrete types, std::stop_source, std::inplace_stop_source and std::finite_inplace_stop_source<N> could then specify independently how to obtain an "associated stoppable_token".

[lewissbaker]

Addressing this should be tackled as part of the same paper written for #42.

[lewissbaker]

We have discussed this in an authors sync meeting.

We can update the stoppable-source concept and it's description later as part of the next revision/wording for P3409, which is going to be forced to deal with this.

It doesn't have any design/semantic implications as the concept isn't used outside of the general description of stop-tokens (there is no API usage of this concept), it is just a wording device/convenience.