This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.
istreambuf_iterator::pointer
should not be unspecifiedSection: 24.6.4 [istreambuf.iterator] Status: New Submitter: Jonathan Wakely Opened: 2019-02-21 Last modified: 2019-10-30
Priority: 3
View other active issues in [istreambuf.iterator].
View all other issues in [istreambuf.iterator].
View all issues with New status.
Discussion:
The current working paper requires iterator_traits<Iter>::pointer
to be void
if Iter
doesn't define operator->
(24.3.2.3 [iterator.traits]). We recently removed operator->
from istreambuf_iterator
via LWG 2790(i), therefore either its pointer
member should be
void
, or there should be a partial specialization of iterator_traits
. Do we want to change
unspecified to void
in the class synopsis in [istreambuf.iterator]?
[2019-03-03, Daniel provides concrete wording]
[2019-03-05 Priority set to 3 after reflector discussion]
[2019-03-05, Daniel comments]
With the acceptance of P1252R2 the committee decided to deprecate operator->
of move_iterator
, interestingly without mentioning what should happen with its current pointer
typedef (which
is equal to the template parameter Iterator
and thus never void
). Effectively this is a very similar situation
as for the here discussed istreambuf_iterator
case and it seems attractive to me to solve both cases similarly.
[2019-10-30, Jonathan comments]
Also, reverse_iterator::operator->()
is now constrained and so not always defined, but
reverse_iterator::pointer
is defined unconditionally.
Proposed resolution:
This wording is relative to N4800.
Change class template istreambuf_iterator
synopsis, 24.6.4 [istreambuf.iterator], as indicated:
template<class charT, class traits = char_traits<charT>> class istreambuf_iterator { public: using iterator_category = input_iterator_tag; using value_type = charT; using difference_type = typename traits::off_type; using pointer = voidunspecified; using reference = charT; […] };