-
Notifications
You must be signed in to change notification settings - Fork 4
Description
24.4.2 Ranges [range.range];
§24.6.1.2 Class template empty_view [range.empty.view];
§24.6.3 Class template iota_view[range.iota.view];
§24.7.6.4 views::take [range.take.adaptor];
§24.7.8.3 views::drop [range.drop.adaptor]
Due to the ranges API being more or less fixed after shipment, API-breaking fixes have to be scheduled now rather than shipped in C++23. The papers p1664 and p1739 represent important and ultimately source-breaking changes to the ranges API. Unless shipped, these API optimizations will result in source code breaking at a later date if attempted to be fixed later, and also makes it impossible to reliably simplify the return value of ranges for a wide variety of current and future adaptors and algorithms. These changes are imperative for developing better APIs and it would be unfortunate to not be able to do them post-C++20 due to source breaking changes. All of the changes except for p1664's two new exposition-only concepts have been approved by LEWG during review of p1739. However, p1664 was discussed as part of p1739's approval and this comment was to be expected.
Proposed change:
The fix and its motivations have been formalized in two papers, [p1664 - Reconstructible Ranges] and [p1739 - Type preservation for forwarding Ranges for "subrange-y" views]. Further fixes are applied through Corentin Jabot's and Casey Carter's [p1391] and [p1394].