Regarding conditional relocation and end-of-scope

[ecatmur]

I have a few questions:

• How do we forbid reloc x + reloc x?
• What about x + reloc x or reloc x + x?
• What about x, reloc x? x or reloc x? x[reloc x]?
• For automatic variable x, after the ternary conditional p ? void(reloc x) : void(), is x destroyed (before end of scope of x) if p converts to false? If so, when exactly?
• What about in (p ? throw : void()), reloc x?
• What happens if a goto, break or throw (in a previous expression-statement) skips over reloc x?
• In if (false) reloc x; did we consider destroying x immediately instead of at end of scope? Does this bear adding to discussion?

[SebastienBini]

If reloc x appears in an expression, then;

• if it appears within a ternary branch, then x cannot be mentioned again outside the ternary expression and within the ternary branch. It is allowed to appear in the ternary condition and the other branch.
• otherwise x cannot be mentioned again in the expression.

We need code like this to work:

std::lock_guard guard{m};
if (!do_stuff())
{
  reloc guard; // lock is released
  process_error();
  return;
}
do_other_stuff(); // here the lock is still held

If reloc x is not evaluated, then x is not destroyed/relocated. Any code that jumps over it will not trigger the destruction of x. However x can no longer be named. I don't know if we can otherwise. Consider:

void foo(CopyOnly x, bool test)
{
  if (test)
    bar(reloc x);
  else
    foobar(x);
  do_stuff();
}

We cannot call the destructor of x at the end of the else branch as maybe x is an unowned parameter.

[ecatmur]

otherwise x cannot be mentioned again in the expression.

Does "again" mean lexically afterward? If so this would allow x + reloc x (possibly unsafe), x = reloc x (definitely unsafe). I think it would be best to kill the name in the whole of the expression, whether lexically before or after, except in clear-cut cases (ternary conditional, comma operator, perhaps built-in logical operators, perhaps list-initialization).

[SebastienBini]

Sorry, "again" means before or after in the expression.

We also need to make sure that this statement is ill-formed:

T x;
T x = reloc x;

Although it could make sense somehow.

perhaps built-in logical operators, perhaps list-initialization

What do you have in mind?

[ecatmur]

And also:

T x; { T x = reloc x; }

Yes - the problem is that in the latter declaration-statement it's well established that x refers to itself - this can even be useful, occasionally: void* p = &p;. We can certainly say that reloc x shall not appear in x's initializer. Even more elegant would be for reloc x to denote any previous x, allowing constification without even needing a different name. Possibly too elegant, but it'd be nice to document as a possibility.

perhaps built-in logical operators, perhaps list-initialization

OK, so I think we want to allow the following only:

• x ? reloc x : reloc x
• x, reloc x (on condition this is the built-in comma operator and not an overloaded comma operator)
• x or reloc x, x and reloc x (similarly)
• std::initializer_list<int>{x, reloc x}, A{.m = x, .n = reloc x}

[ecatmur]

do_other_stuff(); // here the lock is still held

Ah, yeah - it'd be weird to behave any other way. This should be in the paper as apologia.

We cannot call the destructor of x at the end of the else branch as maybe x is an unowned parameter.

Yes. Copy-only unowned parameters make me uncomfortable, but that's for #15.

[SebastienBini]

And also:

T x; { T x = reloc x; }

Yes - the problem is that in the latter declaration-statement it's well established that x refers to itself - this can even be useful, occasionally: void* p = &p;. We can certainly say that reloc x shall not appear in x's initializer. Even more elegant would be for reloc x to denote any previous x, allowing constification without even needing a different name. Possibly too elegant, but it'd be nice to document as a possibility.

That's worth adding a note yes. It would be nice. Personally I still prefer IIFE to the new reloc pattern, and I doubt it would change even if we allowed T x = reloc x; (because the mutable object gets its own scope).

OK, so I think we want to allow the following only:

* `x ? reloc x : reloc x`

Yes.

* `x, reloc x` (on condition this is the built-in comma operator and not an overloaded comma operator)

Yes.

* `x or reloc x`, `x and reloc x` (similarly)

Yes. But no for x or reloc x, x and reloc x (comma being part of the expression.

* `std::initializer_list<int>{x, reloc x}`, `A{.m = x, .n = reloc x}`

Given that the language guarantees that x is evaluated before reloc x (which I am honestly not sure about), then yes.