[io_context.exec.comparisons] requires calls to non-const functions

[jwakely]

[io_context.exec.comparisons] defines equality in terms of calls to context() but that is non-const so can't be called on the const-qualified arguments to the equality operator.

[chriskohlhoff]

On Thu, Oct 8, 2015, at 05:47 AM, Jonathan Wakely wrote:

[io_context.exec.comparisons] defines equality in terms of calls to context() but that is non-const so can't be called on the const-qualified arguments to the equality operator.

Any preference between const_cast and adding an expositional member?

[jwakely]

hmm ... seems a shame to add the member just for this ... but using const_cast would be UB if we had:

io_context c;
const auto e = c.get_executor();
e == e;

How about:

Returns: addressof(io_context::executor_type(a).context()) == addressof(io_context::executor_type(b).context()).

Obviously no sane implementation would do that :-)

Actually, if that's valid, should we just make context() a const function?

[chriskohlhoff]

On Thu, Oct 8, 2015, at 07:35 AM, Jonathan Wakely wrote:

Actually, if that's valid, should we just make context() a const function?

Yes, I think that might be best. I took a look at the relationship between polymorphic allocators and memory resources, as the relationship is conceptually similar. In that case, the allocator's resource() accessor is const and returns a non-const pointer.

But if we do this should the executor requirements also change? That's a slightly larger modification.

[jwakely]

Hmm, good point. Maybe this should be discussed in LEWG not just the two of us.

[chriskohlhoff]

On Thu, Oct 8, 2015, at 08:37 AM, Jonathan Wakely wrote:

Hmm, good point. Maybe this should be discussed in LEWG not just the two of us.

I'll make your suggested wording change to fix this issue, and raise another ticket to cover the wider design question.

[chriskohlhoff]

On second thoughts, no I wont... the copy constructors postcondition is defined in terms of operator== so that would be circular.