Date: Mon, 2 May 2022 20:14:42 +0100
On Mon, 2 May 2022 at 19:10, Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Then don't allow relocating a function parameter.
>
> Parameters are always destroyed by the caller and this is required by the
> standard, not the ABI. Therefore, regular parameters shouldn't be
> relocatable.
>
expr.call says:
It is implementation-defined whether the lifetime of a parameter ends when
> the function in which it is defined returns or at the end of the enclosing
> full-expression. The initialization and destruction of each parameter
> occurs within the context of the calling function.
That doesn't actually say that it's the caller that performs destruction,
only that the "context" of destruction is the caller; my understanding is
that this refers to access control. To my belief, MSVC regard their ABI as
performing destruction by the callee.
Unless you add a new type of reference, which we don't want.
>
An attribute, perhaps. [[no_unique_address]] is precedent for attributes
affecting ABI.
std-proposals_at_[hidden]> wrote:
> Then don't allow relocating a function parameter.
>
> Parameters are always destroyed by the caller and this is required by the
> standard, not the ABI. Therefore, regular parameters shouldn't be
> relocatable.
>
expr.call says:
It is implementation-defined whether the lifetime of a parameter ends when
> the function in which it is defined returns or at the end of the enclosing
> full-expression. The initialization and destruction of each parameter
> occurs within the context of the calling function.
That doesn't actually say that it's the caller that performs destruction,
only that the "context" of destruction is the caller; my understanding is
that this refers to access control. To my belief, MSVC regard their ABI as
performing destruction by the callee.
Unless you add a new type of reference, which we don't want.
>
An attribute, perhaps. [[no_unique_address]] is precedent for attributes
affecting ABI.
Received on 2022-05-02 19:14:55