Date: Fri, 23 Dec 2022 10:13:29 +0100
On Thu, Dec 22, 2022 at 7:02 PM Edward Catmur <ecatmur_at_[hidden]>
wrote:
> Yes, such as `reloc guard, f();` - note the comma. I think here `f()`
> should be protected by the guard.
>
To @Edward Catmur <ecatmur_at_[hidden]> , @magfr_at_[hidden]
<magfr_at_[hidden]> :
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.
wrote:
> Yes, such as `reloc guard, f();` - note the comma. I think here `f()`
> should be protected by the guard.
>
To @Edward Catmur <ecatmur_at_[hidden]> , @magfr_at_[hidden]
<magfr_at_[hidden]> :
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.
Received on 2022-12-23 09:13:44