wt., 1 lut 2022 o 18:37 Gašper Ažman via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> For anyone considering callee-cleanup to be a desirable direction, please know that the general thought is more towards caller-cleanup and that callee-cleanup was a mistake.
>
> There are disagreements on the issue, but I don't think any feature that would end up mandating either of those will pass the committee. We're having similar issues with contracts (albeit there, we're having issues only on callee-cleanup arches).
>

Could you elaborate on why "callee-cleanup was a mistake"? In case of
`std::unique_ptr` it could allow more optimal code.
Because both `sd::move` and destructor would happen in the same
function and allow the optimizer to remove it using the as-if rule.
What is missing there? Only thing I see that could be changed is the
lifetime of `const T&` and `T` will be different.
Where are more problems with this?

> On Tue, Feb 1, 2022 at 5:31 PM Bjorn Reese via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> Just adding another failed attempt to the fray.
>>
>> I explored another venue that uses stateful metaprogramming to enable or
>> disable member functions. The basic idea was to use constrain member
>> functions on compile-time counters. A ultimate goal was to disable
>> destructors if their "destructive move constructor/function" had been
>> called.
>>
>> Unfortunately that did not work out because metaprogramming is not aware
>> of control flow, so enabling or disabling member function did not work
>> correctly with conditional statements or loops.
>>
>> http://breese.github.io/2021/06/06/almost-affine.html
>> http://breese.github.io/2021/06/13/obscurable-types.html
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals