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 T 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
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0593r3.html#direct-object-creation>'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_at_[hidden]>
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_at_[hidden]>
> To: ub_at_[hidden]
> CC: Jens Gustedt <jens.gustedt_at_[hidden]>, Uecker, Martin
> <Martin.Uecker_at_[hidden]>, Hal Finkel <hfinkel_at_[hidden]>
>
> 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
>