Yes, such as `reloc guard, f();` - note the comma. I think here `f()` should be protected by the guard.
As reloc share similarities with temporaries, I'd expect the destructor of guard to be called when temporaries are destroyed, that is at the end of the expression evaluation afaik. The lock should be released at the same moment as in the following expression: `lock_guard{mutex}, f();`
As whether the lock protects f() or not, I really cannot say as I avoid comma expressions as much as I can '^^
I don't see the benefits of making it ill-formed for immovable types, while I clearly see some benefits of allowing it. A function taking a lock_guard by value needs not do anything different than before, since lock_guard has no relocation constructor. If the ABI allows it, then `reloc guard;` will call the destructor, otherwise it's ill-formed.
OK. I want to avoid making discarded-value expressions magic, but maybe we can accomplish that by having the relocation occur (or potentially occur) at temporary materialization, as you've suggested.
That seems like the best approach.
The other thing I want is for well-formedness of code (here `reloc guard;`) to not be platform-dependent. So `reloc guard;` is always valid, but may prevent linking a calling TU compiled by an old compiler or under an old standard.
Yes, well-formedness is important. I don't know how to make `reloc guard` always valid without breaking the ABI even more...
Things are already complex enough, and I don't believe that is required to have for the MVP. So I'd say that relocation+destroy must be legal, although relocation may be elided (so `reloc guard;` is ill-formed because immovable). This is suboptimal, but at least it doesn't close the door to future evolutions. And another proposal can be made later, especially when we have a first feedback on how well the ABI evolution was handled by library/compiler vendors.