New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handling the Ranges TS once merged into the standard #130
Comments
Replacing Instead of using |
Wherever the library implements special handling of utility::identity, provide the same level of support for std::identity when it is available.
Instead of introducing |
After having tried to replace Instead I plan to add support for The number of additional overloads to |
The groundwork for the concepts part is advancing slowly, mostly because the concepts used by cpp-sort are slightly different from those used by the standard library, especially in the following areas:
Support for a more powerful The new iterator/sentinel model is more complicated than I expected it to be, so things aren't going quite fast and I need to change more parts of cpp-sort than expected, but I'm pretty confident that the end result makes it worth the cost. |
There are currently several papers in flight related to merging (parts of) the Ranges TS into the C++ IS. Those changes might come soon enough and will have a deep impact on several parts of cpp-sort, opening the way for a 2.0.0 breaking release. The following papers should be reviewed during the committee meetings to come:
cpp-sort 2.0.0 will have to take all those changes into account in order to modernize itself. The following changes will be needed to fully adapt:
operator++
andoperator--
, so we might have to reimplement a few concepts).std::identity
should be used instead ofcppsort::utility::identity
(we could conditionally make it an alias in cpp-sort 1.x.y).std::less<>
andstd::greater<>
as the main comparison functions (vocabulary types), but add support forstd::ranges::less
andstd::ranges::greater
where it makes sense.std::ranges::
return the past-the-end iterator, we will have to update every sorting algorithm to reflect that, and also to make sure that sorter adapters correctly return it too. I'm still not sure what to do with sorter adapters and Return type of sorter adapters #134.std::swap
,std::size
,std::begin
andstd::end
by calls tostd::ranges::swap
,std::ranges::size
,std::ranges::begin
,std::ranges::end
which should do exactly the right thing.cppsort::utility::iter_move
andcppsort::utility::iter_swap
can be replaced by the equivalent functions instd::ranges::
, and since they automate the lookup we can stop explicitly using the correspondingusing
in some algorithms (do they?).std::projected
can most likely be used to replacedetail::projected_t
.std::contiguous_iterator_tag
or the newContiguousIterator
concept can be used to optimize a few internal algorithms, but it's unlikely that sorting algorithms specific to that tag exist; we still need to check that nothing breaks when it is used.Some of the issues described here are tracked in specific issues too, but an exhaustive list of the changes made by the Ranges TS is valuable enough. My main concern currently is that some of the things we do with our custom proxy iterator support are actually beyond the scopes of Ranges: I fear that
associate_iterator
will break.The text was updated successfully, but these errors were encountered: