Constness of Stop Request

I'd recommend asking this as a normal(debugging) question instead of an open-eneded question. You can delete it and then repost as normal.

From a standard perspective gcc's implementation would be conforming.

Implementations do not need to implement member methods verbatim as specified in the standard. They are allowed to make changes as long as any call that would be valid with the specified function definition is also valid with the modified one.

For example requeststop could be declared as any of the following declarations while still being standard compliant:

// specified signature
bool requeststop() noexcept;
// Adding const does not change behavior
// when calling requeststop() on a non-const stopsource
bool requeststop() const noexcept;
// ... neither do defaulted arguments:
bool requeststop(int i = 0) noexcept;
// or deducible or defaulted template arguments:
template
bool requeststop() noexcept;

1. Both are right - the standard only specifies that requeststop must be callable on non-const stopsources. Whether or not it is also callable on const stopsources is not specified and as such is implementation defined.

2. There's no general answer to that. Both behaviors are possible and it's up to the author of the wrapper class to decide if they want to propagate const or not.
   For example std::uniqueptr does not propagate const - you can still modify the pointed-to object even with a const std::uniqueptr.
   std::vector would be an example of the opposite, it does propagate const - you can't modify the elements the vector points to with a const std::vector.

3. Yes suppressing the warning is a good workaround. GCC does not diverge from the standard though - it is well within its rights to mark the method as const.

1. GCC 13 is wrong-ish. The warning should be ignored, and I blame it's existence on the GCC implementation.

2. It's up to each type to decide whether it's pointer data members point to things that should be logically part of the object, but aren't because of whatever reason, and thus should propogate constness when dereferenced; or aren't, and thus don't need to. The committee decided that the shared state was part of stop_source.

3. In this case you portably can't. I would suppress the clang tidy warning rather than code around it, noting that GCC 13 diverges from the standard. You can add the comment // NOLINT(readability-const-variable) to the line declaring s

cppreference is right. It should be non-const method.

As work around

#if defined(GNUC) && !defined(clang) // Possibly add version too.
using stopsource = std::stopsource const;
#else
using stopsource = std::stopsource;
#endif

"as long as any call that would be valid with the specified function definition is also valid with the modified one." means gcc is non-conforming, right? According to the standard, I can call request_stop on a non-const object, but adding the const breaks that.

To break it down:

• [...] an implementation may declare a different set of member function signatures [...]

  Implementations are free to change the signature of member functions (and that includes making them const, adding additional defaulted (template) parameters, adding additional overloads, etc...)

  ... with one restriction:

• [...] any call to the member function that would select an overload from the set of declarations described in this document behaves as if that overload were selected.

  Implementations only need to preserve behavior if overload resolution against the declarations described in the standard would succeed.

  Note that this does not apply if overload resolution against the standard declarations does not succeed, e.g.:

  std::stopsource sc;
  // no overload of requeststop in the standard matches these arguments
  // => unspecified behavior, might compile or not depending on implementation
  sc.requeststop(0);
  

  Also note that only the behavior of the function must be preserved, not its signature (and that includes things like cv-qualifiers and ref-qualifiers)

std::stopsource sc;
sc.requeststop();

But that can also be satisfied by making requeststop const, e.g.:

class stopsource {
  // ...
  bool requeststop() const noexcept;
  // ...
};

because const qualified methods can be called on non-const objects.

This however would be implementation-defined, because the standard only defines a non-const version of requeststop():

const std::stopsource sc;
// no overload of requeststop in the standard matches for a const stopsource
// => unspecified behavior
// might work, might not work, depending on implementation
sc.request_stop();

See also CWG2259, which updated the wording in place for this paragraph back in C++17.
It explicitly mentions in bulletin 3 that cv-qualifier and ref-qualifier changes should be permitted for implementations.

Looks like I cannot delete it any more, because others (you) already spent time answering my question.

So the GCC stopsource should be fixed? And wouldn't that also mean, that the stopsource copy constructor and assignment operator are somewhat questionable? It would be alright, I guess, if these would accept a non-const reference argument instead, although that would be quite unusual for a copy constructor or assignment operator. But, well, a const stopsource is more or less a stoptoken, right?

Thanks. I think I prefer the NOLINT workaround, though. But I just checked, requeststop really seems to be non-const in libc++ (Clang): https://github.com/llvm/llvm-project/blob/main/libcxx/include/stoptoken/stop_source.h

You can flag it, requesting mods to delete it. Answers (actually comments) would need to be reposted (as answers) but it is how it is.