[libcxx-commits] [PATCH] D102135: [libcxx][ranges] adds _`copyable-box`_
Arthur O'Dwyer via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Tue Jul 6 06:54:31 PDT 2021
Quuxplusone added inline comments.
================
Comment at: libcxx/include/__ranges/copyable_box.h:40-41
+
+template<class _Tp>
+concept __copy_constructible_object = copy_constructible<_Tp> && is_object_v<_Tp>;
+
----------------
ldionne wrote:
> cjdb wrote:
> > Please move this to `<concepts>`: I plan to use this elsewhere! Also, it should be:
> > ```
> > template<class _Tp>
> > concept destructible_object = destructible<_Tp> && is_object_v<_Tp>;
> >
> > template<class _Tp>
> > concept move_constructible_object = move_constructible<_Tp> && destructible_object<_Tp>;
> >
> > template<class _Tp>
> > concept copy_constructible_object = copy_constructible<_Tp> && move_constructible_object<_Tp>;
> > ```
> > (If we need `constructible_object_from`, I'll add that later.)
> I suggest that we instead move it to `<concepts>` when we have that second use for it. As it is, it's really an implementation detail of `copyable_box`.
>
> Also, http://eel.is/c++draft/range.copy.wrap#1.1 says:
>
> > `copyable-box<T>` constrains its type parameter `T` with `copy_constructible<T> && is_object_v<T>`.
>
> `copy_constructible<T>` already includes `destructible<T>` transitively (via `constructible_from`, at least).
+1 @ldionne. Also, there's certainly no need to introduce multiple subsuming concepts here. Subsumption is a tool for solving a problem (namely, concept overloading); we should use the tool if-and-only-if we are solving that problem (or of course if the paper standard is mandating us to do so).
================
Comment at: libcxx/include/__ranges/copyable_box.h:47
+ class __copyable_box {
+ optional<_Tp> __val_;
+
----------------
ldionne wrote:
> cjdb wrote:
> > Can this be `[[no_unique_address]]`?
> There's really no point in doing that AFAICT, because `std::optional` is never empty.
`[[no_unique_address]]` also has a layout effect on non-empty types, if they're tail-padded: https://godbolt.org/z/qjMWo699x
However, AIUI, its effect never leaks out of a type altogether: it makes a difference //only// on a member of `X` that is directly followed by another member of `X`. So if you have a class with only one data member, like this version of `__copyable_box`, then adding `[[no_unique_address]]` to that unique data member will never make a difference. (I think.) https://godbolt.org/z/K3GPPaxbz
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D102135/new/
https://reviews.llvm.org/D102135
More information about the libcxx-commits
mailing list