[libcxx-commits] [PATCH] D118736: [libc++] Guard std::ranges under _LIBCPP_HAS_NO_INCOMPLETE_RANGES.

[Louis Dionne via Phabricator via libcxx-commits]

ldionne added a comment.

In D118736#3295682 <https://reviews.llvm.org/D118736#3295682>, @Quuxplusone wrote:

> In D118736#3295144 <https://reviews.llvm.org/D118736#3295144>, @ldionne wrote:
>
>> 
>
> The content in `<filesystem>` is just opting into view-ness and/or borrowed-ness for certain existing types. I think that's harmless. The //only// reason I disabled it in this PR right now is because my chosen criterion was "When the macro is present then `namespace ranges` is //not// present, period."

Right.

> The content in `<functional>`, i.e. `ranges::less` etc., is also stateless empty types, like `ranges::distance`, where again it's quite possible that their //implementation// will change but their //struct layout// definitely won't. So if (if!) our criterion is going to be "enable the empty types and disable the non-empty types," then `ranges::less` should be enabled, as should all of the algorithms we've implemented so far (which maybe is the empty set ;)).
>
> Is this kind of what you had in mind with "concrete views" and "concrete types" — basically a criterion of "any non-empty type should be guarded by the macro"?

Yes, although I would also remove actual functionality-providing algorithms. I guess it's easier to explain it by saying what we'd keep. The only things we'd keep is whatever is necessary for the non-ranges concepts to work, which is (I think) `iter_move` (and perhaps a few others). WDYT?

> I'm still //extremely// hazy on why we're guarding any of this stuff — what failure mode we're afraid of.

What we want to guard against is users starting to use functionality that is going to break in the future (either ABI or API wise). I also want to guard against shipping an inconsistent subset of `<ranges>` because it's going to be a frustrating experience for users. For example, I don't want to ship `ranges::drop_view` since we're not shipping `ranges::drop`. Same goes for `ranges::begin`, since we're not shipping `ranges::cbegin` (yet). [Unless `ranges::begin` is necessary for the non-ranges concepts to work, in which case I would still provide it]


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118736/new/

https://reviews.llvm.org/D118736