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

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