Re: [release] Boost 1.83.0 Release Candidate 1 is available

From: Joaquin M López Muñoz (joaquinlopezmunoz_at_[hidden])
Date: 2023-08-07 16:19:00

El 06/08/2023 a las 1:07, Marshall Clow via Boost escribió:
> On Aug 5, 2023, at 5:11 AM, Rainer Deyke via Boost <boost_at_[hidden]> wrote:
>> On 03.08.23 16:33, Marshall Clow via Boost wrote:
>>> As always, the release managers would appreciate it if you download the
>>> candidate of your choice and give building it a try. Please report both
>>> success and failure, and anything else that is noteworthy.
>>> -- The Release managers
>> Sorry for the very late report, but I think I found a serious regression in either Boost.Stl_interfaces or in Boost.Range.  Some iterators generated by Boost.Stl_interfaces are not accepted by Boost.Range.  This is a regression from Boost 1.82.  Minimal example program, with basic_input_iter taken directly from a Boost.Stl_interfaces test:
> I have reproduced this with Apple clang version 14.0.3 (clang-1403.0.22.14.1) on ARM64,
> And have confirmed that this compiles w/o error with boost 1.82.0 on the same configuration.
>
> Does anyone have any ideas about what is going wrong here, and how to fix it?

Looks like the iterator_concept -> iterator_category mapping used here 
is incomplete:

https://github.com/boostorg/stl_interfaces/blob/develop/include/boost/stl_interfaces/iterator_interface.hpp#L650-L676

The mapping is copied verbatim from zip_transform_view as spelled out at:

https://eel.is/c++draft/range.zip.transform.iterator#1

I guess this is ok for zip_transform_view, but the description of the 
mapping explicitly says

"The member typedef-name iterator​::​iterator_category is defined if and 
only if Base models forward_range."

Note the "if and only if", implying that if Base only models input_range 
then iterator​::​iterator_category
is not defined.

FWIW, the attached patch makes the snippet compile. It simply adds and 
input_iterator_tag -> input_iterator_tag
case to the mapping algorithm.

Joaquín M López Muñoz