On Wednesday, August 28, 2013 12:27:38 AM UTC-7, B= engt Gustafsson wrote:

=20 =20 =20

Nicol Bolas skrev 2013-08-28 01:17:

On Tuesday, August 27, 2013 2:43:33 AM UTC-7, Bengt Gustafsson wrote:

Zhihao Yuan skrev 2013-08-27 01:57:
> On Mon, Aug 26, 2013 at 7:22 PM, Howard Hinnant
> <howard....@gmail.com> wrote:
>> Question for Zhihao:
>>
>> Why does forward iterator's operator*() have to return a value_type& ?
>>
>> I'm well aware that this is what C++98/03/11 requires. That's not what I'm asking. I'm asking what= is the benefit of this requirement in the C++1y context? What problem does this requirement solve?
> Afaics, it makes the pointed object modifiable. And move_iterator
> significantly benefits from it. (Here is something I'm not sure:
> move_iterator requires only InputIterator, while dereferencing an
> InputIterator may return anything convertible to T -- is there anything
> broken here?)
>
No, he must be refering to something else, as the return value of
vector<bool>::iterator::operator* does indeed make the pointed object
modifiable.

I don't like when people speak in riddles to make other people feel like
idiots! Please instead try to explain the issue at hand as clearly as
you can.

The prime example I have been given of the badness of the vector<bool>
specialization is that it does not have a .data() method. So be it, but
in what case is using .data() preferred to using iterators?

Because it's part of std::vector's interface. std::vector *requires* that this code works:

vector<T> t{...};
T* tp =3D &t[0];
tp +=3D 3;
*tp =3D=3D t[3];

And that will work for all T... so long as T is not `bool`.

It is not for you to decide whether this is good code or not. That's the interface that `vector` provides by the standard, and that is the interface that we should expect to have. And we do... as long as T is not `bool`.

No, the standard says exactly what the standard says: The code above should work for all T except bool. There is a special clause in the standard detailing that vector<bool> is to be specialized to NOT work as you claim. That's what we are discussing here, isn't it? You can claim that we should change the standard because it is inconsistent or confusing but can NOT claim that we should change the standard because it contradicts itself!

=
Which is good because I never said anything about contradicting = itself. You asked for someone to "explain the issue at hand", and I did. `v= ector<bool>` does not behave like a `vector` and it should. Th= at's the issue at hand.

=20 Personally I am indifferent, as I don't use vector<bool>. But I don't want the standard to be changed under the feet of people, and I dislike that more than it being clumsy as it is.

Have you read anything in this thread? The plan for changing thi= s is to add a drop-in class that provides the same interface, so that peopl= e can simply find/replace within their code. Then we deprecate the `vector&= lt;bool>` specialization. It will still be there for at least one versio= n alongside the stand-alone class. That way, everyone has several years and= version releases to do that find/replace within their code to use the new = class rather than `vector<bool>`.

And then we cut out the `vec= tor<bool>` specialization. Nobody is suggesting that it be changed "u= nder the feet of people".