Drop Readability requirement on basic_iterator::operator++(int) about cmcstl2 HOT 6 CLOSED

This is going to need some care to ensure that the stream iterators and inserters (which are implemented with basic_iterator) still meet their specifications. I would be surprised if there is any test coverage.

from cmcstl2.

to ensure that the stream iterators and inserters [...] still meet their specifications

I don't think they can in general. How does istream_iterator<IAmNotMovable>::operator++(int) work?

EDIT: so maybe istream_iterator istream_iterator::operator++(int) requires Movable<T>();. Or void istream_iterator::operator++(int);

from cmcstl2.

I don't think they can in general.

Yes, I didn't mean generally so much as "for the cases that are not already broken." IIRC istreambuf_iterator uses the basic_iterator postincrement proxy support; it will be more broken if we simply yank things out.

EDIT: so maybe istream_iterator istream_iterator::operator++(int) requires Movable<T>();. Or void istream_iterator::operator++(int);

My istream_iterator currently requires:

DefaultConstructible<T>() // We can't "istream >> t;" without creating a T somehow
&& CopyConstructible<T>() // Copying iterators requires copying T
&& StreamExtractable<T, std::basic_istream<charT, traits>> // requires istream >> t

with assignment operations provided by destroy+construct if required in semiregular_box<T>. It would not be a huge leap to require Semiregular<T>().

from cmcstl2.

&& CopyConstructible<T>() // Copying iterators requires copying T

Technically, since this is an input iterator, you could hold a shared_ptr<T>. All copies can share the same T. The only place you need to copy is in op++(int), and I'm trying to kill that.

from cmcstl2.

to ensure that the stream iterators and inserters [...] still meet their specifications

And specifications can change, BTW.

from cmcstl2.

Technically, since this is an input iterator, you could hold a shared_ptr<T>

Yes, I know, but eww allocation.

And specifications can change, BTW.

I'm trying to eliminate undocumented discrepancies between cmcstl2 and D0459R1. If e.g. back_inserter doesn't meet the specification in D0459R1 because we gutted its post-increment operator, there must be a comment that summarizes the discrepancies and a link to the github issue discussing those discrepancies. Mentioning that here reminds me to evaluate the effect of the basic_iterator changes on the iterators when porting the change.

from cmcstl2.