Date: Fri, 31 Oct 2025 07:54:24 +0000
On Fri, 31 Oct 2025, 00:08 Frederick Virchanza Gotham via Std-Proposals, <
std-proposals_at_[hidden]> wrote:
> On Thu, Oct 30, 2025 at 4:28 PM Jeremy Rifkin wrote:
> >
> > What does this paper add to the existing body of papers,
> > nb comments, and discussion regarding what relocatable means?
>
>
> I have added two new headings to my paper:
>
> - What about std::restart_lifetime? (from P2786)
> - What about std::relocate?
>
> Under these two new headings, I describe my proposed changes to how
> relocation should work in C++, and I have included a fully-portable
> implementation of std::relocate.
>
> You can see the latest draft of my paper here on "std::relocatability"
> here:
>
> http://www.virjacode.com/papers/relocatability.htm
The standard is not defined in terms of "a possible implementation". What
are the semantics you're proposing? Are you proposing that the reserved
name _Relocate have special meaning? (Why?) And that there should be a
magic special case for arm64e that doesn't handle any future architectures
that have similar behaviour?
This seems far too focused on specific implementation details that you've
observed, and not on a useful design.
>
std-proposals_at_[hidden]> wrote:
> On Thu, Oct 30, 2025 at 4:28 PM Jeremy Rifkin wrote:
> >
> > What does this paper add to the existing body of papers,
> > nb comments, and discussion regarding what relocatable means?
>
>
> I have added two new headings to my paper:
>
> - What about std::restart_lifetime? (from P2786)
> - What about std::relocate?
>
> Under these two new headings, I describe my proposed changes to how
> relocation should work in C++, and I have included a fully-portable
> implementation of std::relocate.
>
> You can see the latest draft of my paper here on "std::relocatability"
> here:
>
> http://www.virjacode.com/papers/relocatability.htm
The standard is not defined in terms of "a possible implementation". What
are the semantics you're proposing? Are you proposing that the reserved
name _Relocate have special meaning? (Why?) And that there should be a
magic special case for arm64e that doesn't handle any future architectures
that have similar behaviour?
This seems far too focused on specific implementation details that you've
observed, and not on a useful design.
>
Received on 2025-10-31 07:54:42
