istreambuf_iterator::pointer should not be unspecified
Jonathan Wakely

Created on 2019-02-21.00:00:00, last changed 2019-03-05.22:28:07.


Date: 2019-03-05.22:28:07

Proposed resolution:

This wording is relative to N4800.

  1. Change class template istreambuf_iterator synopsis, [istreambuf.iterator], as indicated:

    template<class charT, class traits = char_traits<charT>>
    class istreambuf_iterator {
      using iterator_category = input_iterator_tag;
      using value_type        = charT;
      using difference_type   = typename traits::off_type;
      using pointer           = voidunspecified;
      using reference         = charT;
Date: 2019-03-15.00:00:00

[ 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.

Date: 2019-03-05.00:00:00

[ 2019-03-05 Priority set to 3 after reflector discussion ]

Date: 2019-03-15.00:00:00

[ 2019-03-03, Daniel provides concrete wording ]

Date: 2019-02-21.00:00:00

The current working paper requires iterator_traits<Iter>::pointer to be void if Iter doesn't define operator-> ([iterator.traits]). We recently removed operator-> from istreambuf_iterator via LWG 2790, 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]?

Date User Action Args
2019-03-05 22:28:07adminsetmessages: + msg10345
2019-03-05 18:54:44adminsetmessages: + msg10340
2019-03-03 16:32:51adminsetmessages: + msg10330
2019-03-03 16:32:51adminsetmessages: + msg10329
2019-02-21 00:00:00admincreate