Date: Thu, 30 Oct 2025 12:06:49 -0700
> On Oct 30, 2025, at 10:14 AM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>
>
> On Thursday, October 30, 2025, Thiago Macieira via Std-Proposals wrote:
>>
>> We're just not going to use the feature. It's not the first time we ignore a
>> Standard feature because we think we can do something better and will not be
>> the last.
>
>
>
> I'm dumbfounded that there are some people here who think that invoking an encryption algorithm is 'trivial'. Utterly dumbfounded.
The fact that an operation is not trivial on your hardware does not make that true on other hardware. On my machine that “non trivial” behavior happens on pointer indirection. Or we can consider MTE protection on some systems: now every byte you copy requires performing a bunch of bitwise operations on your pointer, loading a value from an unrelated region of memory, comparing the values, and conditionally trapping. Is that also non trivial? Because it sounds like a lot of work.
So let’s stop with arguments from incredulity, they are not valid anywhere, certainly not a standards body. If you wanted to raise issues, you should have read the specification and raised them earlier.
However you have not expressed a single thing at all that has not previously been said, and as multiple people in this thread have said there are plenty of NB comments that agree with you.
On a practical matter I have no problem with _either_ definition of what “trivial” means, all that matters is whether polymorphic types are required to be relocatable. If polymorphic types are required to be relocatable, then the current definition of trivial relocation is a requirement, if it were instead specified as being a bitwise identical copy we would require the relocatability of polymorphic types to be either disallowed or implementation defined.
Any of these are fine by me, the semantics of what a trivial relocation is are entirely dependent on how polymorphic objects are to be specified, and any of them are implementable under the arm64e ABI, or the aarch64+pac ABI.
This is something I discussed at length with the proposal authors a very long time ago when I first read the proposal, and the current version of the proposal is what was accepted.
As a footnote: this thread is descending into arguments that have been made previously, and have been raised in NB comments for Kona, so we should not be flooding the list with the same arguments again, as nothing on this list can impact anything about the specification at this point.
—Oliver
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
>
> On Thursday, October 30, 2025, Thiago Macieira via Std-Proposals wrote:
>>
>> We're just not going to use the feature. It's not the first time we ignore a
>> Standard feature because we think we can do something better and will not be
>> the last.
>
>
>
> I'm dumbfounded that there are some people here who think that invoking an encryption algorithm is 'trivial'. Utterly dumbfounded.
The fact that an operation is not trivial on your hardware does not make that true on other hardware. On my machine that “non trivial” behavior happens on pointer indirection. Or we can consider MTE protection on some systems: now every byte you copy requires performing a bunch of bitwise operations on your pointer, loading a value from an unrelated region of memory, comparing the values, and conditionally trapping. Is that also non trivial? Because it sounds like a lot of work.
So let’s stop with arguments from incredulity, they are not valid anywhere, certainly not a standards body. If you wanted to raise issues, you should have read the specification and raised them earlier.
However you have not expressed a single thing at all that has not previously been said, and as multiple people in this thread have said there are plenty of NB comments that agree with you.
On a practical matter I have no problem with _either_ definition of what “trivial” means, all that matters is whether polymorphic types are required to be relocatable. If polymorphic types are required to be relocatable, then the current definition of trivial relocation is a requirement, if it were instead specified as being a bitwise identical copy we would require the relocatability of polymorphic types to be either disallowed or implementation defined.
Any of these are fine by me, the semantics of what a trivial relocation is are entirely dependent on how polymorphic objects are to be specified, and any of them are implementable under the arm64e ABI, or the aarch64+pac ABI.
This is something I discussed at length with the proposal authors a very long time ago when I first read the proposal, and the current version of the proposal is what was accepted.
As a footnote: this thread is descending into arguments that have been made previously, and have been raised in NB comments for Kona, so we should not be flooding the list with the same arguments again, as nothing on this list can impact anything about the specification at this point.
—Oliver
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-10-30 19:06:56