Niall's Dxxxx "Enhanced C/C++ memory and object model" refers to P1434R0 "Discussing Pointer Provenance."
P1434R0 contains the following text.

Equality of pointers is handled by a case analysis:
  • [...]
  • if both are valid, have different provenance and compare equal, then [...]
  • if both are valid and have different provenance, [then] they compare not equal
The two bullet points I quoted are contradictory. The second says "two pointers with different provenance never compare equal," and the first says "if two pointers with different provenance compare equal, then..."

Because of inconsistencies/typos/thinkos like this, I doubt that P1434R0 is a firm footing on which to base anything at the moment. Is there a P1434R1 in the works?

Niall:

An object of trivially copyable, standard-layout , trivially attachable, or trivially detachable type (X.X) shall occupy contiguous bytes of storage.

The added "or" changes the meaning of the black text from "trivially copyable AND standard-layout type" to "trivially copyable OR standard-layout type." This can't possibly be intentional.  I think you meant "... AND trivially detachable"; but I recommend just eliminating this green text entirely. All objects — even objects of non-trivially attachable types — continue to occupy contiguous bytes of storage, IIUC.

A ‘reachable C++ program’ can be defined by the implementation as one of the following options [...]

Memory pages can be concurrently accessible to more than one reachable C++ program at a time

Avoid using the phrase "can be" in normative text. Probably what you mean is that the implementation is required to define "reachable C++ program" and required to permit concurrent access to pages; but taken literally, all this text is saying is that the implementation can do those things (it doesn't have to).

An object of type shall have trivial attachment or detachment if [...]

I think you meant to use the phrasing "An object of type T is said to have trivial attachment if..." Otherwise, you're putting a requirement on (somebody) that T have trivial attachment, without ever having defined what that means.
Separately, you seem to be defining "trivial attachment" as the opposite of "non-vacuous attachment," is that right? If so, that's unnecessarily confusing. The opposite of "non-vacuous" should be "vacuous," and the opposite of "trivial" should be "non-trivial."

It's not obvious to me what you mean by "trivially obvious changes," nor how "trivially obvious" differs from "obvious."

Your `auto in_place_attach<T>(span<byte>) -> span<T>` is extremely reminiscent of P0593R3's not-yet-proposed-but-likely-to-get-proposed `auto bless<T>(void *p) -> T*`.  It would be nice to compare and contrast what's going on there, or even try to harmonize the two papers.

As trivially attachable and detachable types have default attachment and detachment implementations in this proposal, that would mean that all types without pointers and references within them can now be relocated. This substantially expands the number of types whose move constructor and move assignment could be defaulted, and whose representation can be transported in CPU registers instead of on the stack.

I think I agree with the gist of this section, but I don't understand what you mean by "This substantially expands the number of types whose move constructor and move assignment could be defaulted." Relocation-by-detachment-and-attachment has nothing to do with move-construction, let alone move-assignment.

    struct file_descriptor {
        int fd = -1;
        file_descriptor(file_descriptor&& rhs) noexcept : fd(rhs.fd) { rhs.fd = -1; }
        ~file_descriptor() { if (fd != -1) close(fd); }
    };

This `struct file_descriptor` should be "trivially relocatable" by anyone's definition. But it obviously can't have a defaulted move-constructor, because it does not have a defaulted destructor. RAII types must still follow the Rule of Three / Rule of Five.  And higher-level types can follow the Rule of Zero. Higher-level types following the Rule of Zero will already default all their special members and thus do not gain anything in that department from being "trivially attachable and/or detachable."

my $.02,
–Arthur


On Tue, Mar 26, 2019 at 5:24 PM Niall Douglas <s_sourceforge@nedprod.com> wrote:
Bounced due to low attachment size limit. I uploaded a copy of the draft
paper to:

https://dedi5.nedprod.com/static/files/other/Dxxxx%20draft%202%20-%20Enhanced%20C%2B%2B%20memory%20and%20object%20model.pdf

Niall

-------- Forwarded Message --------
Subject: Draft 2 of Enhanced C/C++ memory and object model
Date: Mon, 25 Mar 2019 13:16:10 +0000
From: Niall Douglas <s_sourceforge@nedprod.com>
To: ub@isocpp.open-std.org
CC: Jens Gustedt <jens.gustedt@inria.fr>, Uecker, Martin
<Martin.Uecker@med.uni-goettingen.de>, Hal Finkel <hfinkel@anl.gov>

Dear SG12,

CC: Relevant members of WG14, and Hal

Please find attached draft 2 of my upcoming SG12 and WG14 targeted paper
proposing an enhanced memory and object model for C++ and C based around
implementing a subset of P1434 "Discussing pointer provenance" to make
much more rigorous the modification of memory, and adding two new core
operations to objects:

1. Detachment, the reinterpretation of a live object into an array of
bytes representing that object.

2. Attachment, the reinterpretation of a previously detached object
representation into a live object.

It is believed that these changes are sufficient to implement memory
shared between concurrent processes, memory mapped in from another
device by DMA, process bootstrap from a database of shared binary
Modules, and the elemental operations for implementing zero-copy
serialisation and deserialisation.

One also gains object relocation in memory, and substantially enhanced
default move implementations which can use CPU registers for object
transport.


I appreciate that this proposal is huge, the standardese in the paper
meagre and incomplete, and chances of success are very low. Still, I
hope to discuss it at Cologne and subsequent SG12 meetings, if Gaby
wishes to give time to it. I'll also be taking it to the May WG14
meeting, and see how much the C folk hate it.

Feedback is welcome.

Niall