Eric Niebler

> Yes, the P1716 did make it through LWG in Colonge. I think you either mean "did _not_", or else you mean LEWG.

I seem to recall am email to lwgchair about this, and the response was that an issue was inappropriate. I think this needs an NB comment.

Might be better to simply add the requirements in prose without requiring an implementation to diagnose failures.

I think part of the problem here is that we're trying to be overly general with this concept by trying to support types that do not represent a logical or...

After perusing the current working paper, there are output iterators that have non-`const`-qualified `operator*` members, so this change probably won't fly for `writable`. However, all the _input_ iterators have `const`-qualified...

> `Writable` performs gymnastics to apply requirements to both `T&&` and `T&` without requiring `const`, presumably to allow `optional` to satisfy `Writable`. No, the gymnastics in `writable` are so that...

> We're talking about completely different gymnastics. Ah. > If we were happy to require writable's expressions to work with const-qualified iterators... No, I don't think we are. Lots of...

Ack, no! There is a reason _`ITER_CONCEPT`_ is left as an implementation detail. It defaults to `std::random_access_iterator_tag`, which is _wrong_ for the majority of iterators. It is only useful as...

> Is there an existing trait I've overlooked? No. I would probably implement the trait as a function with cascading `if constexpr (foo_iterator)` tests that returned the tag type, wrapped...

I don't think this is wrong, _per se_. If the iterator fails to meet the requirements of _cpp17-input-iterator_ (and doesn't specify the nested iterator type aliases and doesn't specialize `std::iterator_traits`)...