Date: Sat, 13 Jul 2024 11:08:42 -0400
On Sat, Jul 13, 2024 at 10:23 AM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:
>
> Annotating the variable itself is important because guaranteed NRVO
> means that the lifetime of the object will be extended beyond the
> scope of the function.
>
> One of the biggest issues with guaranteed NRVO is that it
> fundamentally changes the meaning of the code. A local variable is not
> *local* anymore; it *will* persist beyond its evident scope.
[...]
> Your rules now require that this code works. The user is following the
> rules of guaranteed NRVO, so `retvar` *must* persist beyond the scope
> of the function call. As such, `ptr` *must* point to `var`.
>
That's one very reasonable model for "guaranteed NRVO." I *think* (but I'm
not sure off the top of my head) that that's the model used by P2025.
But it's not the only possible model.
Another possible model is that the lifetime of `var` really truly has
ended, and a new object of the same type has begun its lifetime at the same
address. Pointers and references to the old object `var` are invalidated at
this point. However — by core-language magic — this has occurred without
calling any constructor or destructor.
This gets you your UB (and optimization/escape-analysis opportunity), and
also your runtime efficiency, at the same time.
*But it requires wording to get there.* Which P2025 attempted, and which
this std-proposals thread certainly isn't attempting (and shouldn't be: if
you have a *real* idea, put it in a paper or something).
Relevant reading:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
https://cplusplus.github.io/CWG/issues/2868.html
and probably several other CWG issues.
my $.02,
–Arthur
std-proposals_at_[hidden]> wrote:
>
> Annotating the variable itself is important because guaranteed NRVO
> means that the lifetime of the object will be extended beyond the
> scope of the function.
>
> One of the biggest issues with guaranteed NRVO is that it
> fundamentally changes the meaning of the code. A local variable is not
> *local* anymore; it *will* persist beyond its evident scope.
[...]
> Your rules now require that this code works. The user is following the
> rules of guaranteed NRVO, so `retvar` *must* persist beyond the scope
> of the function call. As such, `ptr` *must* point to `var`.
>
That's one very reasonable model for "guaranteed NRVO." I *think* (but I'm
not sure off the top of my head) that that's the model used by P2025.
But it's not the only possible model.
Another possible model is that the lifetime of `var` really truly has
ended, and a new object of the same type has begun its lifetime at the same
address. Pointers and references to the old object `var` are invalidated at
this point. However — by core-language magic — this has occurred without
calling any constructor or destructor.
This gets you your UB (and optimization/escape-analysis opportunity), and
also your runtime efficiency, at the same time.
*But it requires wording to get there.* Which P2025 attempted, and which
this std-proposals thread certainly isn't attempting (and shouldn't be: if
you have a *real* idea, put it in a paper or something).
Relevant reading:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
https://cplusplus.github.io/CWG/issues/2868.html
and probably several other CWG issues.
my $.02,
–Arthur
Received on 2024-07-13 15:08:59