> On Nov 2, 2025, at 3:27 PM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Fri, Oct 31, 2025 at 11:31 PM Jeremy Rifkin wrote:
>>
>> The reloc named constants you provided still have these magic numbers in the name which is a bit odd.
>
>
> Perhaps out of ordinary, but efficient. If you glance at the
> constant's name, you don't need to go looking in a header file or on
> 'cppreference.com' to figure out what the number is.

You don’t need to know the value of the number, that’s why we use named symbols.

>
> I've done more work on my paper. I've added descriptions of the
> different categories (1 = memcpy, 2 = compiler builtin, and so on).
> Latest draft is here:
>
> https://www.virjacode.com/papers/relocatability.htm


Your paper still does not specify the semantics of this operation. An implementation is not a specification. This has been stated repeatedly.

>
> Furthermore I've pointed out a weakness in 'restart_lifetime', in that
> it's not future-proof, as follows:
>
> restart_lifetime is declared as follows:
>
> template<typename T>
> T *restart_lifetime(T *p) noexcept;
>
> This function is a no-op on all platforms except for arm64e. On
> arm64e, the object’s new address is enough information to correctly
> re-encrypt the vtable pointer.

This is wrong, you need to know the exact type for multiple reasons that were discussed in your prior attempt to make dynamic_cast from void* to work in which you also seemed opposed to providing a specification. I still do not understand why you are so opposed to doing this. Providing a specification is literally the first thing you should be writing after your introduction and motivations. I do not understand why you continue to just provide code dumps despite being told innumerable times that that is neither helpful, nor relevant.

For people who were not part of that prior thread, a basic component of the arm64e ABI is that essentially every vtable pointer (this in an implementation detail) in any object is protected from substitution by incorporating both the storage address and the primary base that introduces that vtable. This necessarily includes those vtable pointers for all base classes, and the vtables of any transitively included polymorphic sub-objects. Relocation does not mean fixing up one vtable pointer, and the fixup is not based on just the address. e.g. a polymorphic object that is a subobject of a non-polymorphic object, will still be usable after relocation as the vtable pointer is fixed up.

Now let’s get to the proposal.

This paper is not a proposal. It tries to be two things: an untimely opposition paper to an approved feature, produced after even national bodies are no longer permitted to provide comments, simultaneously claiming it is removing an accepted feature, while adding multiple new features. The former is part of its inappropriate attempt to oppose an accepted paper beyond the date that such opposition should have been presented.

A number of the features it claims to add literally only exist in sentences in which the proposal claims it has added them, and thus there is no specification of any kind. The features it does actually spend time on have no specification presented, there are varying degrees of partial implementation of functions throughout the paper, none of which include any kind specification, many are filled with details explicitly tied to specific implementation details that are not part of, nor observable through, the abstract machine.

No justification is presented for any of the choices it makes, the motivation section being mostly focused on past due opposition to p2786, beyond that the overall feature design is overly complicated and fragile, it is built around an ordering that it does not justify, and the construction of that ordering means that it cannot evolve to support new traits, alongside that many parts of this proposal seem to directly duplicate existing features - certainly the implementation provided implies that most of the arbitrary numbers are simply opaque and arbitrary combinations of existing traits, if not literally having a 1:1 those traits. No justification is presented for why these numbers are superior to the existing traits that they represent. There is a claimed removal of ambiguity, but it provides no evidence that the arbitrary numbers assigned to these traits are somehow better than the preceding traits.

As there are no specifications in this paper I’m forced to try to work out what is intended by reading the code, interpreting the intended behavior solely from the myriad partial implementations included in the paper. From that the proposal seems result in relocation of non-relocatable objects, and claims relocation for objects that are being subject to standard copy or move constructors. The lack of even the remotest effort to provide any kind of specification means it is impossible to tell if and of this is just implementation bugs or intentional behavior.


* Section 1 Is this a proposal for a new feature, or opposition to another? This proposal starts off stating it disagrees with the definition of “trivially relocatable”, but the committee has already agreed on a definition this term, and pending NB comments it is currently accepted into the standard. There have been months to raise objections, in the intent is to oppose P2786 they should have been raised in a timely manner.

Despite starting as if this was intended as opposition for an existing proposal, this paper then appears to introduce a new feature, which is it? You can choose one or the other.

The paper then proposes removing an existing feature, but does not provide any new justifications, or in fact any, that have not already been considered by the committee prior to being accepted into the language. Attempting to shoehorn opposition to an accepted proposal under the guise of a new feature is inappropriate, and should be a separate core proposal, not intermingled with new features. Though trying to remove or change an existing defined term in the standard after the point it has become officially part of the standard requires significant motivation, and you disagreeing with it is unlikely to meet that bar. None of the opposition or points you have raised are new, and all of them have been considered previously, and considered insufficient.

Despite claiming to remove the definition of “trivially relocatable”, no part of the proposal includes any such change, nor any discussion of the impact of that removal.

You then provide a set of 13 possible values, but there is no justification for any of them - honestly these do not belong in the introduction - but this problem would no go away by placing them in a different section. There is no explanation for the ordering, and there is no explanation of what makes these numbers superior to traits. There is a set of constants declared but the naming explains nothing, and seems to encode the numeric value of the in the name, implying that the number itself is important. This is a novel addition to the standard, and there is no motivation presented.

* Section 2 The motivation section would again imply that this paper is meant as an opposition paper in response to p2786, in which case it is being presented far too late. There was a very long window to raise concerns or oppositions with p2786, and then there was a window in which concerns could have been raised with your national body, but even that has passed. This paper is in no way timely, and therefore it is inappropriate to submit it now.

Despite the stated motivation being opposition to an accepted proposal after the cut off date for even NB comments, this proposal then continues in an attempt to add a new feature to the language.

Seemingly the only motivation for this feature is disapproval of the accepted language of p2786, which is not a valid motivation.

The motivation states that a numeric categorization removes ambiguity but I cannot see how this it does this as the ordering seems to be arbitrary. In fact the motivation states "A numeric classification removes ambiguity by explicitly stating how a type can be relocated", but I cannot see how a developer can see the number -4 and know what that means, or how it unambiguously states how a type is relocated? How is this less ambiguous than `is_move_constructible_v<T>`? The constants listed in the introduction are even named in a manner that indicates they are simply wrappers around the existing unambiguous trait names. Moreover this list of mechanisms for relocation is incorrectly including types that are not relocatable, as indicated by its use of traits that are very clearly unrelated to relocation.

* Section 3 using an attribute to specify behavior is a fundamental category error, that is why p2786 has a contextual keyword. Attributes are ignorable so should be used to impact semantics. You also appear to have just described pod types, so there is no need to have a new definition. You’ve just described a trivial and standard layout class.

Moreover you don’t define what happens if this is applied to a type that has non-default copy or move constructors, or if it transitively contains them, or how it inherits. You need to actually write a specification.

* Section 4 What is a “compiler builtin”? This is an implementation detail, which is not part of the specification. It’s possible you mean a fundamental type, but this entire section seems to be devoted to implementation details that are not part of the abstract machine?

* Section 5 As is becoming typical of this paper, there is no specification of this interface, just some code that implements something, does this API only apply to types named File? Is the API permitted to simply zero all the memory? What happens if the function cannot complete? During resolution this function could be found on the base class of a type that is not relocatable, is that allowed? There’s no specification that says it is. In a later section you have a pile of code, is that an example implementation, or is that specification? Regardless that code says that it does not matter whether a type has a custom constructor, destructor, is polymorphic, or anything - because the base class has specified this interface it will be relocated. It is unclear if this is intentional because you have not included any specification for any part of this proposal anywhere.

* Section 6 Why are there categories 4-7 if they’re all the same?

* Section 7 fails to specify the behavior of the API, the preconditions, or postconditions of the API, and indeed fails to specify any of the semantic details. Instead it provides a partial implementation of something? We cannot tell what the implementation is of as there is no specification, and the proposal just refers to compiler builtins, despite those definitionally not being part of the specification and are artifacts of implementing features that have specified behavior. They have no business being discussed in a specification, because they are not a part of the standard. Again specifications are not about implementations, they are specifications, and implementations ensure that they then implement them as specified, that may involve internal functions of a specific implementation, or they may not. This is not something that matters in a specification.

* Section 8 provides a “possible implementation”, but a possible implementation of what? There is no specification provided, and an implementation is required to attempt to reverse engineer the specification. As someone who spent many years fixing web specifications to match reality, following a decade or so of incorrect or incomplete specifications where the path to implementation was reverse engineering other implementations, I would not recommend this approach. This section also makes use of functions that don’t exist in the standard. The example implementation is include ifdefs about platform targets, implying it is not operating according to the specification of the abstract machine.

* Section 9, I question these design decisions:
 * There is no justification for the categories, from reading the code it would appear that many appear to exactly match existing traits, why do we need duplicates for these traits? Later implementations seem to just perform `== random number` so this is literally just a wrapper around `is_existing_trait_v<T>`.
* integer classification
* What does the ordering of preference even mean? How is “preference” defined? It seems completely arbitrary - how does this compare to the normal resolution of copy constructors, move constructors, or assignment operators? If it is the same, why does this not reference that - possibly by factoring the selection test out? If it is a different ordering, why?
* This numbering presumes that there will be no additional additions in future that are not lower preference than existing options, thus any future additions will necessarily not be supported in this API.
* Why are these raw numbers? Why are they not named? Why are these specific numbers important? Would implementation defined be better, with some constraints applied?
* Signedness conveys exception throwing:
* Why is this communicated through the same channel as indicating the preference? This choice merely increases the complexity of an already complex API, and if it does exist anywhere else in the specification I would presume it is in older specification additions that cannot be removed.
* Why is the preferential ordering of exception throwing operations reversed relative to their non-exception throwing counter parts
* `T::std_relocate`: is there any existing precedence for this? How does it differ from move constructors beyond simply having a loop? There are already existing mechanisms for moving multiple objects.
* `Compiler built-ins` what are compiler builtins? There’s no definition of them anywhere, it sounds like another call to implementation details instead of writing a specification.

* Section 10. We have no idea what the impact on the standard is as you have not provided a specification. The addition of a header? A header that does what? Why is this in a separate header? These queries largely appear to be traits related, and in fact most directly wrap existing traits without any apparent justification, so the existing type_trait header would seem likely the best target, if there were an actual specification. The proposal as written introduces a slew of new terms that need to be introduced, and many seem to be very complicated, including the addition of the concept of a “compiler builtin” a something that has never previously existed. The proposal adds many references to vtables in a way that implies the intention of adding them to the standard which would require significant modifications to the semantics and definitions of polymorphic objects.
* Section 11 an implementation of something with no discussion of what it does or why, a bunch of references to cpus that are not relevant because cpus do not exist in the abstract machine. A claim that the paper proposes _another_ API, `restart_lifetime`, but it does no such thing, and so there is no way to determine what the random implementation is intended to do, as it not only does not provide a specification, but even the provided implementation is unusable as it uses a non existent function that tautologically has no defined semantics.
* Section 12 just has a large implementation of … something? It is unclear what, or why it does anything it is doing? It also seems to be evaluating throwing relocation operators in the reverse order to what was previously claimed as the preferred order. The implementation also has ifdefs around specific cpus which is confusing as this is meant to be part of the C++ standard, so such conditions definitionally do not exist.

—Oliver