Tweak wording of the triviality requirement

[dtolnay]

It isn't actually a requirement that the type have no destructor as brought up by the previous paragraph. Rather, it just needs to be safe for values of that type to be moved via Rust's memcpy-based move semantics.

The distinction is relevant e.g. for struct S { s: String } which would have a C++ destructor and nontrivial implicitly defined move constructor but still be safely memcpy movable. C++ has no analogue of "trivially destructive-movable" which is the semantic we are really interested in.

[adetaylor]

struct S { s: String } is safely memcpy movable?

I assume you mean:

struct S {
  std::string s;
}

in C++ terms. My understanding is that std::string has a pointer which may or may not be self-referential, depending on the length of the string (and possibly the STL implementation?) so isn't safely memcpy-able.

(This wording's fine, though, of course!)

[dtolnay]

No I do mean struct S { s: String }, with a Rust string, i.e. struct S { rust::String s; };. It is safely memcpy movable as long as your move semantics are destructive, as in Rust.

This is connected to the last paragraph of the comment in #338.

To support structs like this in #297 the is_trivially_move_constructible/is_trivially_destructible condition is going to need to change. I think I would prefer not to just outright remove the static assert, even though that would be sound (as justified by #338). Instead I think we are going to end up doing some template metaprogramming of our own to add a disjunction which we enable automatically for cxx-generated shared structs or a user could enable from C++ for their own struct. (I don't know exactly how; not a C++ expert.)

Pseudocode:

static_assert(rust::is_trivially_destructive_movable<T> // <- from rust/cxx.h
    || (std::is_trivially_move_constructible<T> && std::is_trivially_destructible<T>));

FYI @sbrocket as well.

[adetaylor]

I see.

I would strongly like to keep those static_asserts for C++ types if we can find a way. I agree that from a soundness perspective, it's moot because the user has made a promise. But from a practical perspective with a realistic mess of C++ types, it's really difficult for a developer to figure this stuff out, so I think those asserts are extremely valuable.

I think the plan of a new C++ template sounds like the right plan to me.

[dtolnay]

I would strongly like to keep those static_asserts for C++ types if we can find a way. I agree that from a soundness perspective, it's moot because the user has made a promise. But from a practical perspective with a realistic mess of C++ types, it's really difficult for a developer to figure this stuff out, so I think those asserts are extremely valuable.

Understood. I agree with this.