Date: Wed, 2 Mar 2022 14:16:47 +0100
śr., 2 mar 2022 o 14:02 Bo Persson via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> On 2022-03-02 at 12:15, Maciej Cencora via Std-Proposals wrote:
> > You may assume whatever you want, but behaviour of your program may
> > change depending on consume impl (because managed resource will be
> > destroyed at different times).
> > And without language level move/relocate, the only way to workaround
> > this problem is to x = {}, after the consume call - but that requires
> > default constructiblity which may not be possible/may be costly.
>
> The only way?!
>
> What about letting x go out of scope? That's what I usually do when I
> don't need an object any more.
>
Letting x go out of scope is possible only sometimes, if x is by-value
function parameter, you are out of luck.
Anyway I certainly would not want to see such workarounds in real
code, because the intention is not clear without a comment, and it
uglifies the code.
'move x' (or 'relocate x' as in OPs proposal) on the other hand
clearly signals intention, and doesn't uglify the code.
<std-proposals_at_[hidden]> napisał(a):
>
> On 2022-03-02 at 12:15, Maciej Cencora via Std-Proposals wrote:
> > You may assume whatever you want, but behaviour of your program may
> > change depending on consume impl (because managed resource will be
> > destroyed at different times).
> > And without language level move/relocate, the only way to workaround
> > this problem is to x = {}, after the consume call - but that requires
> > default constructiblity which may not be possible/may be costly.
>
> The only way?!
>
> What about letting x go out of scope? That's what I usually do when I
> don't need an object any more.
>
Letting x go out of scope is possible only sometimes, if x is by-value
function parameter, you are out of luck.
Anyway I certainly would not want to see such workarounds in real
code, because the intention is not clear without a comment, and it
uglifies the code.
'move x' (or 'relocate x' as in OPs proposal) on the other hand
clearly signals intention, and doesn't uglify the code.
Received on 2022-03-02 13:17:00