Sorry for not reading the whole big discussion (it would be nice to have
another platform for this), but is no one has yet suggested using
const rvalue reference (const T&&) as relocate constructor tag?
Then specifiy situations when it is used(NRVO/RVO things or similar), when
this relocate constructor is used compiler do not generates destructor call
for this variable
Then add
template<typename T>
constexpr decltype(auto) std::die(T&& v) noexcept {
  return std::move(std::as_const(v));
}
And it is undefined behavior to call destructor on variable after relocate
ctor/operator used(for example value relocated from vector)
(Another way - we can explicitly forbit to do ill formed using this ctor
for not local variables or atleast constexpr / global variables...)
And this consrtuctor is not created implicitly, but can be ONLY = default:
Type(const Type&&) = default;
behaves as if:
constexpr Type(const Type&& v) noexcept {
memcpy(this, std::addressof(v), sizeof(*this)); // pseudocode
}
Type& operator=( const Type&&) = default;
behaves as if:
constexpr Type& operator=(const Type&& v) noexcept {
  std::destroy_at(this); // pseudocode
  std::construct_at(this, static_cast<const Type&&>(v);
}
This ctor and operator also must be ill-formed if type has virutal
inheriting or one of fields contains initializer to another field of this
class or base type is self-referenced
And it is undefined behavior to call this operator and ctor on self
reference types (when it cant be deducted on compile time) ( also
implementations can check it on runtime on debug, its really possible to
generate such = default operator=, which will check all pointers/references
in fields or bases)
Even If base classes do not have relocate contructors or operators =
default will generate them by those rulls
Then add support std::is_relocatable_v<T> and stl optimizations with it.
Nice?

вс, 18 сент. 2022 г. в 20:27, Edward Catmur via Std-Proposals <
std-proposals_at_[hidden]>:

> On Fri, 16 Sept 2022 at 11:05, Sébastien Bini <sebastien.bini_at_[hidden]>
> wrote:
>
>> Hi Edward,
>>
>> Thank you for those explanations. I'll get in touch with people from
>> AFNOR when we have a draft ready (ongoing).
>>
>> There is still one technical aspect that we haven't talked about:
>> structured binding relocation.
>>
>> I believe that, in order to support relocate-only types, we need to
>> enable relocation from a structured binding: `auto [x, y] = foo();
>> sink(reloc y);` must work. This is motivated by:
>>
>> - The need to make APIs that support relocate-only types. How do you
>> write an API to extract an item at an arbitrary position from a vector? I
>> suggest the following: `std::pair<iterator, T>
>> vector<T>::pilfer(const_iterator);` (returns next iterator and relocated
>> vector element) as it is consistent with other vector APIs and complies
>> with the core guidelines
>> <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-out>.
>> Then, what can users do with the returned object as it lies in a pair, and
>> that it is forbidden to relocate only parts of an object? The return value
>> is unusable for relocate-only types, unless we support structured binding
>> relocation.
>> - Almost all C++ developers that I know believe that a structured
>> binding is complete, separate object, and not a name alias to some
>> subobject. As such they would find it weird that they cannot relocate a
>> structured binding.
>>
>> Yes, all good points, and I agree this would be very useful.
>
>
>> This is not a blocking point IMO, but will be very nice to have. vector's
>> pilfer can be worked around by rotating the element to the end of the
>> vector and calling some new vector::pilfer_back method that removes and
>> returns the last element. There is no performance overhead, it is just
>> cumbersome to write. Likewise we can just state that we cannot relocate a
>> structured binding and move on with the proposal. But I'd like to give it
>> more thoughts: structured binding relocation sounds like a very convenient
>> facility, and after all, how hard could it be to just relocate one item of
>> a pair? Well it's not simple :/
>>
>> Before we dive in, let's agree to reuse the terms used in
>> https://en.cppreference.com/w/cpp/language/structured_binding . As such,
>> when we write: `auto [x, y] = foo();` it creates a hidden object `e` of
>> type `E` (which is the return type of `foo`), `x` and `y` are newly
>> introduced identifiers that are just aliases to some parts of `e`.
>>
>> The best approach I can think of is that under some conditions, `x` and
>> `y` are not aliases but individual complete objects, and no hidden object
>> `e` is created. Hence we can write `reloc x` without violating the rules we
>> added (which forbids relocation of subobjects). Here are the conditions:
>>
>> - there must be no ref qualifiers in the auto declaration (auto [x,
>> y] = foo(); passes, auto const& [x, y] = foo(); doesn't)
>> - `E` must not have a user-defined destructor, a user-defined
>> relocation, move or copy constructor. This should give us the guarantee
>> that we can safely split an object into individual objects. Thankfully for
>> us, std::pair and std::tuple comply.
>>
>> That part is fine by me. The question is then how do we construct each
>> individual object that corresponds to the new identifiers we introduced? We
>> need to distinguish between the three binding protocols supported in C++17:
>>
>> - C array: the easiest of the three, each object is constructed
>> element-wise using the best-suited constructor. That approach remains
>> compatible with relocation.
>>
>> Yes. Interestingly, you don't see array prvalues much, since they can't
> be returned from functions, but they do exist as temporaries (auto&& r =
> std::type_identity_t<int[2]>{0, 1} constructs a temporary array and binds
> it to a reference).
>
>>
>> - Binding to data members: again, no real difficulty here, each
>> object is constructed using the best-suited constructor from their
>> corresponding data member. Again that approach remains compatible with
>> relocation.
>>
>> Yes, this is fine.
>
>>
>> - Tuple-like binding: this is the hardest of all, and probably the
>> one we need to support the most. The main problem with tuple-like binding
>> is that the language doesn't treat std::array, pair and tuples as specials.
>> They are just types like any other, hidden behind the tuple_size,
>> tuple_element and std::get APIs. We can construct each object using the
>> member get (or std::get) functions, and that will work fine for copy
>> constructor and move constructor, but not for relocation. First, the get
>> functions will return references and not prvalues, so the relocation
>> constructor will not be selected. Second, the get functions, had they
>> returned by value, will not be allowed to relocate the subobject they
>> return. Last, we have no warranty that tuple_size and all the get functions
>> return a partition of `E`. It is mandatory to enable construction of the
>> new objects (`x` and `y`) by relocation, as again, the whole point of this
>> is to support relocate-only types (so `x` or `y` may be relocate-only).
>>
>> The only solution that I can think of is an alternative API for the
>> tuple-like binding protocol. If that new API is not provided then we
>> fallback to C++17 structured bindings that cannot be relocated. The API I
>> think of is:
>>
>> - A template static member function get_member that returns the
>> pointer to I-th data-member: `template <std::size_t I> auto
>> E::get_member<I>()`
>> - Or a get_member free function that does the same: `template <class
>> E, std::size_t I> auto get_member()`
>>
>> The return type of the get_member function must be:
>> `std::tuple_element_t<E, I> (E::*)`. The number of supported get_member
>> must match that of tuple_size<E>::value. For std::pair, that would be:
>>
>> template <class First, class Second>
>> constexpr auto get_member<std::pair<First, Second>, 0> { return
>> &std::pair<First, Second>::first; }
>> template <class First, class Second>
>> constexpr auto get_member<std::pair<First, Second>, 1> { return
>> &std::pair<First, Second>::second; }
>>
>> Let's consider the expression: `E e = foo(); auto [x, y] = reloc e;`. If
>> E provides the new API then the new objects (`x` and `y`) can be
>> constructed by relocation. The language needs to track, if any relocation
>> constructor is used, which subobjects of the source (`e`) got destructively
>> relocated into a new object of the "structured binding". Then the
>> destructor of the source object is not called directly. Instead the
>> language will call the destructor on all the subobjects of the source that
>> were not relocated (we need to keep in mind that relocation may not happen
>> for every data-member, and that some data-member may be hidden from the
>> tuple-like binding API). Hopefully, thanks to the pointer to data-member
>> returned by the get_member functions, the language is able to track down
>> which parts are relocated and which aren't.
>>
>> I thought of just taking the address of whatever std::get returns,
>> instead of introducing a new API. However I don't believe we have any
>> guarantee that std::get returns a reference, and even a reference of some
>> subobject that lives within the tuple-like object (it could very well be a
>> reference to some static variable...). get_member solves both those
>> problems.
>>
>> I am not sure this is the best solution there is, I am just sharing my
>> thoughts about the subject. If get_member seems viable, we can easily
>> provide an implementation for pair and tuples. I wonder what can be done
>> with std::array (we cannot take the pointer to data-members that are array
>> elements, although the language considers array elements as subobjects...).
>>
>
> Yes, I agree this would be nice to have, but as well as the problems you
> have noticed with `get_member`, there is also the problem that pointer to
> data member of a nested (not base class) subobject cannot be formed, and
> also that there could be tuple-like classes that form some elements "on
> demand".
>
> I have another idea, which is to use recursion in the manner of
> operator->(). For example, let's say that structured binding for
> tuple-like class types first looks for
> `get<std::make_index_sequence<std::tuple_size<E>::value>>(reloc e)` (the
> exact syntax isn't important, but it should be something clearly novel and
> `e` should be prvalue if the original object was). Then, whatever this
> call returns (which must have the same `tuple_size` as `E`) is in turn
> submitted for structured binding (as a prvalue).
>
> Of course, library authors will then need to create a struct type with the
> appropriate number of fields, but it won't be difficult for compiler
> authors to write an intrinsic to do that, and once it's available for
> std::tuple and std::array then everyone else can just recurse to those
> types. Anyone who can't/ doesn't want to recurse to the Library can use
> preprocessor hackery, other code generation, or possibly metaclasses (once
> those are available), to support any sensible number of elements.
>
> It'd be ugly to convert `std::array<T, N>` to essentially `struct { T t0,
> t1, ...tn-1; };` but N should be small (at least until we get variadic
> structured binding) and compiler authors can always hack in a better
> solution for privileged Library classes as long as the general case can be
> made to work for non-Standard library authors. A more ambitious solution
> would be to allow returning arrays from functions.
>
> For example, one could write:
>
> template<std::size_t... I, class... T> requires
> std::same_as<std::index_sequence<I...>, std::index_sequence_for<T...>>
> auto get<std::index_sequence<I...>>(my_tuple<T...> t) {
> union { my_tuple<T...> tt; } = {.tt = reloc t}; // prevent destructor
> return std::tuple<T...>(std::relocate(&get<I>(tt))...);
> }
>
>> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>