Date: Tue, 22 Sep 2026 09:04:59 +0100
On Tue, 22 Sept 2026, 08:40 David Brown via Std-Proposals, <
std-proposals_at_[hidden]> wrote:
>
> As you say, it makes no sense to try to say what "asm" actually does in
> the C++ standards - it cannot be described in terms of the abstract
> machine. But it is feasible to be a little bit clearer on the preferred
> syntax for implementation-specific "asm" extensions so that there is
> minimal chance of conflicts later.
That seems like attempting to solve a hypothetical problem that doesn't
exist.
The standard should not attempt to reserve anything more here than it
already does. Implementations can do what they need to do, and if the
standard needs to change something later, it should be done in a way that
doesn't conflict with existing extensions.
Trying to guess now what future directions the standard might take and then
telling implementations to avoid that is likely to fail. We'll probably
guess wrong, and then have to make different changes anyway.
And it could avoid "register"
> entirely, rather than "re-introducing" it in some way.
>
>
>
std-proposals_at_[hidden]> wrote:
>
> As you say, it makes no sense to try to say what "asm" actually does in
> the C++ standards - it cannot be described in terms of the abstract
> machine. But it is feasible to be a little bit clearer on the preferred
> syntax for implementation-specific "asm" extensions so that there is
> minimal chance of conflicts later.
That seems like attempting to solve a hypothetical problem that doesn't
exist.
The standard should not attempt to reserve anything more here than it
already does. Implementations can do what they need to do, and if the
standard needs to change something later, it should be done in a way that
doesn't conflict with existing extensions.
Trying to guess now what future directions the standard might take and then
telling implementations to avoid that is likely to fail. We'll probably
guess wrong, and then have to make different changes anyway.
And it could avoid "register"
> entirely, rather than "re-introducing" it in some way.
>
>
>
Received on 2026-09-22 08:05:16
