Приращение префикса двунаправленного итератора С++

Это косвенный способ формулирования требований без явного указания конкретной реализации. В частности, &r == &++r — это способ сказать, что ++r не может возвращать прокси-объект. Результатом должен быть тот же итератор.

Здесь mutable не является полной противоположностью const в обычном смысле, но означает «доступный для записи» и снова относится к требованиям для итератора вывода.

Двунаправленный итератор, конечно, должен поддерживать как ++p, так и --p (по определению), но не должен быть доступен для записи/изменения.

Категории не совсем ортогональны между чтением/записью и перемещением вперед/назад, поэтому отдельные требования не являются независимыми, как могли бы быть. Это вызывает некоторую путаницу.

Я не уверен, следует ли ваш вывод из наблюдений, но не думаю, что это будет важной свободой для реализации. Тот факт, что вы должны поддерживать такие вещи, как *++p и *p++, устанавливает большинство ограничений.

Можете ли вы указать, как это требование может повлиять на реализацию?

Очевидный ответ заключается в том, что метод operator++() или operator--() должен return *this, тогда как отдельная функция Foo& operator++(Foo& arg) должна возвращать свой аргумент. Поскольку это в любом случае разумно, большинству реализаций не о чем беспокоиться.

Более сложный вопрос: «Когда итератору (например, прямому вводу) имеет смысл не следовать описанному выше подходу». Я еще не мог привести разумный пример. Даже для константного итератора ввода тип ++r должен быть ссылкой на тип итератора. Таким образом, любая форма «прокси-объекта», как упоминал @Bo Persson в своем ответе, будет работать только в том случае, если этот прокси-объект был подкласс класса итератора. Кажется, это не имеет большого смысла.

У меня такое ощущение, что требование &r == &++r было просто забыто для случая итератора вывода. Я сомневаюсь, что авторы спецификации имели в виду какой-либо конкретный вариант использования, в котором это требование не было бы выполнено. Но я предполагаю, поэтому я с нетерпением жду более надежного ответа на этот вопрос.