Hi all,

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.
>>>>
>>>
I really like this idea. It's a bit of a shame though that std::pair will
have to provide its own get<index_sequence<0, 1>> and perform an extra
relocation, while it could already fit the data-member binding protocol :/
But that's a minor detail.
Nice solution though :)

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))...);
>>>> }
>>>>
>>>
The union trick is a bit hacky, and it's not exception-safe (if exceptions
leak through the std::relocate calls). Also what happens if I want to write
this function for a custom class, but only want to provide a subset of all
data-members? Then, if I use the union trick, I need to manually call the
destructor on all non-relocated data-members...
But well, this is just reserved for library writers so it may be acceptable.

I see another unorthodox solution though. This get<index_sequence> is to be
called by the language, and not manually. Hence what if the signature were:
auto get_bindings<E>(D1 d1, D2 d2, D3 d3, ...), where Di is the i-th
subobject of E in declaration order, passed as prvalue. There are as many
parameters passed as there are subobjects in E. The E template parameter
must not be there if defined as an E's member function (which mmakes the
function non-template). If such a function exists then the language will
manually split E into all of its subobjects by relocation, and make the
function call. We can keep the recursive bit so as long as there exists
such a get_bindings function that matches for the return type, it is
applied.

This way we can safely write our own without being hacky:
template<class... T>
auto get_bindings<my_tuple<T...>>(T... t) {
    return std::tuple<T...>(reloc t...);
}

If we need to retrieve base class data-members, or nested data-members,
that's still doable:
struct B { T _b }; struct D : B { T _d; T_arr[2]; };

template <>
auto get_bindings<D>(B base, T d, T arr[2])
{
auto [b] = reloc base; // calls get_bindings<B>(T) if it exists, or else
relies on data-member protocol.
auto [a1, a2] = reloc arr;
return std::tuple{reloc b, reloc d, reloc a2};
}

When structured relocation is used we can issue a warning if a get_bindings
is declared for the class type but its parameters don't match (it may very
well lead to an error if other binding protocols fail to apply). That way
we can warn the user that they forgot to update the get_binding function
when they changed their class layout.

I know it's unorthodox, but it's safe. I wonder how it mixes with virtual
inheritance; maybe we should forbid such types...

*About tuples:*
Another problem is that there are no std::tuple constructors that allow to
relocate its input parameters. Sure, we could write one, but I fail to see
a good signature. I fear, because of the variadic template, that either all
input parameters are prvalues, or all are forwarding references. With such
a signature we cannot build a tuple by moving its first parameter and
relocating its second.

Acknowledging that, we could simply write (Types... being the std::tuple
template parameters):
std::tuple::tuple(Types... types)

However there are already:
std::tuple::tuple(Types const&... types)
template <class... UTypes>
std::tuple::tuple(UTypes&&... types)

I can already see people asking why the wrong constructor was picked. See
for instance: std::tuple<std::string, RelocOnlyTp, int>{reloc a, reloc b,
reloc c}, but unfortunately c is long long int in our Murphy scenario,
which makes the forwarding reference constructor being picked because of
the type discrepancy. Then the whole thing is ill-formed because `b` is
relocate-only and cannot be moved.

I can think of another solution:
template <class... UTypes>
std::tuple::tuple(UTypes... types)

Using this constructor, all parameters must be passed as prvalues. This
means for users to use reloc on a parameter they wish to relocate,
std::cref on a parameter they wish to copy, and a new std::mref on a
parameter they wish to move (std::mref being a helper function that builds
a new std::move_reference_wrapper. We cannot use std::move because it
returns an xvalue, not a prvalue...). Thankfully for us, std::cref and
std::mref return a prvalue. This tuple constructor would be able to detect
the two kinds of reference wrappers and unwrap them to call the appropriate
constructor.

However I see two potential problems. First, I am not sure how things might
conflict against the tuple(UTypes&&... types) constructor. Second users
have been taught to use std::move since C++11, and now they would need to
use std::mref in some circumstances...