p1664 - ReconstructibleRange

[ThePhD]

We need a concept for ranges that can be put back together. ReconstructibleRange is that concept.

(Or reconstructible_range with all the new concept naming wankery.)

Background from:

• Sentinal-based Ranges should also take end Sentinels ericniebler/range-v3#1190 (comment)
• Ranges which take a sentinel should be constructable from {Iterator, Sentinel} ericniebler/range-v3#1192

[ThePhD]

First draft written since I can't sleep: https://thephd.github.io/vendor/future_cxx/papers/d1664.html

[ThePhD]

Someone else is working on this in p1739, except they're applying it to make sure things are simplified without creating massive amounts of type spew:

https://stackedit.io/viewer?url=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1739r0.md

[Morwenn]

Oooh, I like what is proposed in P1739 :o

[ThePhD]

I had a long discussion about this and got Corentin'd: if we don't make the concept and have it be applicable for a wide variety of ranges alongside the formalization of p1739, it's an API breaking change to optimize it later by adding constructors to applicable ranges which fit ReconstructibleRange, which is what Casey Carter and Hannes Hauswedell.

• ref_view cannot be ReconstructibleRange, so remove from the paper (think of a std::list being referred to by the ref_view: the ref_view has a size because std::list has a size, but the pair of iterators don't so it's not equivalent).
• The rest listed so far seem to be good candidates for ReconstructibleRange, however

I need to flesh out p1664 and combine it with the efforts of p1739, then present both in a reflector e-mail asking for them to be included in C++20, lest we die the death of 1,000 range template class instantiations.

How did I get into this mess 😭 ...

[h-2]

I would propose the following:

template <typename R>
concept pair-reconstructible-range = 
    forwarding-range<std::remove_reference_t<R>> && 
    std::Constructible<std::remove_reference_t<R>, iterator_t<R>, sentinel_t<R>>;

template <typename R>
concept range-reconstructible-range = 
    forwarding-range<std::remove_reference_t<R>> && 
    std::Constructible<std::remove_reference_t<R>, std::ranges::subrange<iterator_t<R>, sentinel_t<R>>>;

i.e. the concepts should be independent, because || them makes no sense (You need to know exactly which of them holds to be able to do anything meaningful). I am not too sure about the remove_cvref_t up there, meddling with that in the context of concepts often has unintended consequences.

I would also mark both exposition-only for now as that reduces some of the stability burden and (hopefully) increases their chance of being added.

Note that if we want empty_view (and iota_view?) to model one of the above concepts we also need to make it model forwarding-range first which is not the case right now (as far as I am aware).

I have P1739 here: https://github.com/h-2/iso-proposals/wiki/Type-erasure-for-forwarding-ranges-in-combination-with-%22subrange-y%22-view-adaptors

I can make an actual file in the repo from it in the next days so you can make PRs. Feel free to e-mail me [h2 æt fsfe · org] about p1739 or work-in-progress on reconstructible ranges.

edit: change remove_cvref_t to remove_reference_t and add requirement for View.

[ThePhD]

Sorry for the wait @h-2: paper is up. https://thephd.github.io/vendor/future_cxx/papers/d1664.html

[ThePhD]

Will be filed as an NB-comment post-Cologne, when the NB Comment period opens up in a few months.

P1739 will be discussed, but the paper is not on-time enough to be counted directly by formal reasoning (but we can still discuss p1664 and let it get published in the post-mailing with the NB Comment).

[ThePhD]

Last minute killed in Plenary.

[ThePhD]

Formally withdrawn.