Object slicing and relocation

[SebastienBini]

Consider the following scenario:

using reloc_only_t = gsl::non_null<std::unique_ptr<int>>;

struct B
{
  reloc_only_t _b;
};
struct D : B
{
  reloc_only_t _d;
};
// B and D are forcibly relocate-only

void sink(B);
void foo(D obj)
{
  sink(reloc obj); // What happens here?
}

Given the rules we established, I'd say this is ill-formed? I'm not sure of how object slicing happens behind the scene, but I guess it involves an extra copy of the base part of the object.

If we had move-only types instead, and had used std::move instead of reloc, the following would have happened in my understanding:

• sink is called with an xvalue of D.
• sink(B) is selected as we can move-construct B from a D xvalue.
• B is constructed in sink's parameter slot, effectively leaving B's part of obj in a moved-from state, and not touching D's part.
• At the end of foo (assuming obj is not an unowned parameter), its destructor is called.

In the general case (with relocate-only types or not), when reloc selects the relocation constructor, I would like to have a similar approach (assuming obj is not an unowned parameter):

• sink is called with a prvalue of D.
• sink(B) is selected as we can relocate-construct B from a D prvalue.
• The non-B parts of obj are destructed.
• B is constructed in sink's parameter slot, by relocating the B's part of obj.
• obj lifetime ends before sink is called.

This would be equivalent to:

struct D : B
{
  reloc_only_t _d;
  B get_B(this D reloc) { return reloc B; } 
};
void foo(D obj)
{
  sink((reloc obj).get_B());
}

Except that it would happen automatically. I suspect it at least requires D to have no user-provided destructor.

What do you think?

[ecatmur]

Yes, definitely, and I agree that D should have no user-provided destructor.

As a further extension, it's plausible that the user might want also to relocate a non-base class subobject, e.g.:

std::pair<reloc_only_t, bool> f();
reloc_only_t g() { return f().first; }

The rules in http://eel.is/c++draft/class.temporary#6.sentence-2 should suffice for identifying cases for which such a subobject relocation would be viable.

[SebastienBini]

Indeed, although that last example could have been done by structured relocation. It could be a nice addition, but I am afraid to open that door.

That would further enable relocation from data-members entirely:

std::pair<reloc_only_t, bool> p;
reloc_only_t f = (reloc p).first;

Also, what happens with this?

template <class T, class Member>
auto extract(T p, Member member)
{ return ((reloc p).*member); }

auto get_reloc_only(std::pair<reloc_only_t, bool> p)
{ return extract(reloc p, &std::pair<reloc_only_t, bool>::first); }

The data-member address is purposely not passed as template parameter, and hence not a compile-time constant when evaluating extract.

Now whether we allow that last bit or not, another question is then, if we don't deal with relocate-only types:

• do we make the program ill-formed if the relocation ctor is selected and the class does not support decomposition?
• or do we prevent the relocation ctor from being selected in the first place if the class does not support decomposition, hence fall-backing to move semantics (better but I don't know if it's possible)?

I purposely speak of decomposition support instead of "no user-provided dtor", as I recall std::decompose had a bucket full of requirements.

[ecatmur]

Indeed, although that last example could have been done by structured relocation.

Yes, but sometimes you want to use the data member name rather than rely on ordering. Also this allows selecting a multi-level member or array element.

That would further enable relocation from data-members entirely:

std::pair<reloc_only_t, bool> p;
reloc_only_t f = (reloc p).first;

Great!

Also, what happens with this?

template <class T, class Member>
auto extract(T p, Member member)
{ return ((reloc p).*member); }

void get_reloc_only(std::pair<reloc_only_t, bool> p)
{ return extract(reloc p, &std::pair<reloc_only_t, bool>::first); }

The data-member address is purposely not passed as template parameter, and hence not a compile-time constant when evaluating extract.

It's a bit of work for the compiler to track which data member is being relocated and which are to be destroyed, but I think it's feasible. It would mean that every base class (or maybe every base class that the data member could be located in) would need to not have a user-supplied destructor.

Now whether we allow that last bit or not, another question is then, if we don't deal with relocate-only types:

• do we make the program ill-formed if the relocation ctor is selected and the class does not support decomposition?
• or do we prevent the relocation ctor from being selected in the first place if the class does not support decomposition, hence fall-backing to move semantics (better but I don't know if it's possible)?

Yes, there has to be fallback to copy/move ctor, otherwise we're breaking existing code (the prvalue object could just be a function return value).

I purposely speak of decomposition support instead of "no user-provided dtor", as I recall std::decompose had a bucket full of requirements.

Yes. To recap, those requirements should be:

• no user-declared rule-of-7 special member functions (on the prvalue complete object class, and every base class down to the base class the member may be found in, or the base class the prvalue is sliced to);
• all said bases, and non-static data members and direct bases of said bases, and all their destructors, are accessible from the context (since the context will be calling their destructors individually).

We don't need to worry about overlapping since only one data member (or base, going back to the start of this issue) is extracted.

[SebastienBini]

That would further enable relocation from data-members entirely:

std::pair<reloc_only_t, bool> p;
reloc_only_t f = (reloc p).first;

Great!

I don't think that's straightforward though. I believe (reloc p).first is an xvalue in today's C++ (data member of a prvalue is an xvalue). We need to tweak the rules if we want it to be considered as a prvalue.

It's a bit of work for the compiler to track which data member is being relocated and which are to be destroyed, but I think it's feasible.

I honestly don't know, but it does look feasible. We can still propose it.

Yes, there has to be fallback to copy/move ctor, otherwise we're breaking existing code (the prvalue object could just be a function return value).

Indeed. Ruling out the relocation constructor from the overload set if conditions are not met is the best approach I can think of.

Yes. To recap, those requirements should be:

* no user-declared rule-of-7 special member functions (on the prvalue complete object class, and every base class down to the base class the member may be found in, or the base class the prvalue is sliced to);

* all said bases, and non-static data members and direct bases of said bases, and all their destructors, are accessible from the context (since the context will be calling their destructors individually).

We don't need to worry about overlapping since only one data member (or base, going back to the start of this issue) is extracted.

Yes.

I believe we are up for a new Implicit object decomposition section ;) I'm still writing the section about decomposing functions, so you can take that bit if you like.

[ecatmur]

I don't think that's straightforward though. I believe (reloc p).first is an xvalue in today's C++ (data member of a prvalue is an xvalue). We need to tweak the rules if we want it to be considered as a prvalue.

Yes. However, it may need to stay an xvalue, first if the complete object cannot be implicitly decomposed and secondly if a reference is bound to a temporary object subobject, extending the lifetime of the complete object [class.temporary].

Would it make sense to write instead reloc p.first, still with the effect of removing p from scope? Alternatively reloc (reloc p).first, but that's pretty ugly. In reloc p.first it's easy to see which variable is removed from scope: it's the one immediately following the reloc keyword.

I believe we are up for a new Implicit object decomposition section ;) I'm still writing the section about decomposing functions, so you can take that bit if you like.

👍

[SebastienBini]

I still prefer (reloc p).first. I find reloc p.first counter-intuitive as it gives the impression that only part of the object is relocated, the rest being valid.

However, it may need to stay an xvalue, first if the complete object cannot be implicitly decomposed...

Then why not simply keep the prvalue and ruling out the relocation ctor?

...and secondly if a reference is bound to a temporary object subobject, extending the lifetime of the complete object [class.temporary].

But that can still be done if (reloc p).first is a prvalue, right?

Also, we might need to pay special attention to arrays:

T arr[5] = { /* ... */ };
foo((reloc arr)[2]);

And if that's supposed to work, it might be worth adding an overload to std::array (and other containers?):

T array<T,N>::operator[](this array reloc, std::size_t id)
{
  return (reloc _arr)[id];
}

[ecatmur]

I think an example will help:

struct S {
    A a;
    B b;
};
S f(int);
auto x = f(1).a;
auto&& y = f(2).a;
auto z = reinterpret_cast<S&>(y).b;  // #3

Note that line 3, while containing a scary reinterpret_cast, is completely valid (on condition A and B are standard layout) - the S temporary returned from f(2) has been lifetime-extended by the reference binding of y to its A data member subobject, and an lvalue to that S can be recovered by the first-member provision.

So f(2).a must be a subobject of f(2), and so it must be xvalue; prvalues are always complete objects.

OK, so let's say that implicit object decomposition occurs (if viable) when a temporary subobject is subject to lvalue-to-rvalue conversion. That would also cover the slice-to-base case. So it would occur in auto x = f(1).a; and in auto&& y = auto(f(2).a);, but not in auto&& z = f(3).a; (which would perform lifetime extension on the temporary S full object instead). (Both of the first two would odr-use the eligible relocation, move or copy constructor of A, but would be permitted to elide it at the cost of wasting stack space.)

Then (reloc p).first would be an xvalue, but reloc_only_t f = (reloc p).first; would be performing lvalue-to-rvalue conversion on a temporary subobject, and so would invoke implicit object decomposition.

Also, we might need to pay special attention to arrays:

T arr[5] = { /* ... */ };
foo((reloc arr)[2]);

Yes, that should work.

And if that's supposed to work, it might be worth adding an overload to std::array (and other containers?):

T array<T,N>::operator[](this array reloc, std::size_t id)
{
  return (reloc _arr)[id];
}

Yes, definitely.

[SebastienBini]

Well, I'm impressed.

I did know of the lifetime extension, but was not aware that prvalues needed to be complete objects, although it does make a lot of sense. Thank you for the detailed explanation.

lvalue-to-rvalue conversion looks like the way to do it. And we can keep (reloc p).first. I tried to find cases where it wouldn't work, and the only thing I could think of is the following:

T foo();
decltype(auto) case1() { return foo().first; }
decltype(auto) case2(T val) { return (reloc val).first; }

I didn't check but I believe that case1 will leak a reference on a temporary.
If I understand correctly case2 will do the same, although the use of reloc might wrongly suggest the opposite (users might expect case2 to return by value).

I don't think that's a blocking issue though, this code is already smelly.

[SebastienBini]

Tackled by #38