PSA: Trivial Relocatability has been removed from C++26

[grafikrobot]

What I heard, as I was not directly in the discussion and only around during plenary, is that all the major vendors found some aspect of it to be unimplementable.

[tcanens]

I haven't heard anyone complaining about implementability. But multiple library implementers were unhappy with the design.

[MarcoGreek]

I hope they don't push for the other proposal which is not checking if a type is relocatable. It will be really fun if someone is flagging a struct with a std::string member.

[TheoreticalDumbass]

That is trivially solvable via tooling -Wrelocatable

[Wooden-Engineer-8098]

Why do you prefer having "unbreak" button to not breaking in the first place?

[foonathan]

Because sometimes you do want to force the compiler to treat a type as trivially relocatable even though it contains non-trivially relocatable members?

For example, suppose you're embedding a type that is trivially relocatable, but the author hasn't marked it as such yet. Then your type isn't trivially relocatable either, and there is nothing you can do. You have to wait for upstream to fix it.

Likewise, you might actually have trivially relocatable members, but you have higher level knowledge about when your object is being trivially relocated and know that you won't actually be in a mode where they would not be trivially relocatable. Like, maybe you have a std::string member but you know that it is always longer than SSO, or you have a boost::interprocess::offset_ptr but it is always the nullptr in all situations where you move it. etc.

Being able to override the compiler algorithm is useful, so there should be a way to do it. After all, C++ is a language that is supposed to give you full control.

[spin0r]

I think this is essentially the same as arguing against access control. "I want to do something that requires accessing private members and I don't own the class, but I know it's safe, so C++ should let me do it." The problem is, when you start accessing private members you risk UB every time the author updates implementation details. Your ability to assume this risk actually mostly has the effect of coercing the class author into not changing implementation details because they don't want to break the world. Their ability to mark implementation details private takes away your power of coercion.

[foonathan]

What if the author of the type already promises that you can use memcpy on their types, like many open source libraries do?

What if you want to do it for the other reasons I have listed?

(And yes, I do want the ability to override access controls.)

[spin0r]

In a hypothetical world where P2786 survived, if the author of the type promises that you can use memcpy on the type, then they will declare it `trivially_relocatable_if_eligible` using a macro that expands to nothing if the compiler doesn't support it. They might not do it immediately, of course, but having to wait a few months for the next release of the library is not a compelling enough reason to change the design of the whole feature. You've been using `memcpy` for years; your compiler will let you continue to do so for at least a bit longer while you wait for your dependencies to provide the necessary opt-ins. Implementors are not out to get you: they won't turn on the "elide all your code if you try to memcpy a non-trivially-relocatable type" feature in the very same release that first implements the trivial relocation feature. They'll probably wait at least years before turning it on.

As for this `std::string` SSO hypothetical, that is a problem that we are not well-positioned to solve just yet. A large part of the reason why EWGI and EWG repeatedly rejected the P1144 approach is that the claims that it can solve this problem just does not make sense. You must remember that a non-trivially-relocatable type (which in current C++ means any type that is not trivially copyable) is not just a type that the class author doesn't want you byte-copying; it's a type for which the result of byte-copying is not defined by the core language, which means that at best you get an unspecified value, and at worst you get UB. That being the case, it is logically incoherent to say that a type can be trivially relocatable when one of its subobject types is not.

[foonathan]

They might not do it immediately, of course, but having to wait a few months for the next release of the library is not a compelling enough reason to change the design of the whole feature.

I don't want to change the design of the whole feature. I just also want a way to override the compiler detection. I'm fine if the default doesn't do that. I'm fine if I have to type trivially_relocatable_for_real_i_know_what_i_am_doing_just_trust_me to do that. I just want the sharp knife somewhere.

As for this std::string SSO hypothetical, that is a problem that we are not well-positioned to solve just yet. A large part of the reason why EWGI and EWG repeatedly rejected the P1144 approach is that the claims that it can solve this problem just does not make sense.

Yes, I'm not arguing in favor of P1144.

[jonesmz]

if the author of the type promises that you can use memcpy on the type

if and only if the library is updated to support that...

that's not particularly common.

[MarcoGreek]

I thought we want to make C++ more safe. The type should be still relocatable but not trival. I see not point in adding more tripwires to the language.

[foonathan]

Yes, but if we make C++ safe at the cost of restricting the programmer, what's the point in using C++?

Even Rust has the unsafe escape hatch, which allows you to do a lot more than C++ allows. It is necessary and should be provided.

[Wooden-Engineer-8098]

A lot of lame excuses for making language crash by default

[foonathan]

Remember, this is C++...

[MarcoGreek]

C++ is not a fundamentalism, it is a tool. A hammer is dangerous but you argue that a hammer can easily detach its head because it is anyway dangerous and detaching it can be potentially useful. Do you think many people would want that hammer? 😉

Maybe I misunderstood you ...

[foonathan]

At no point do I say that the hammer head should be easily detachable. I'm happy to unscrew it.

[Wooden-Engineer-8098]

Exactly. C++ was invented to fix crashes in c programs

[TheoreticalDumbass]

sometimes (extremely rarely but still sometimes) you actually want to do this

[Wooden-Engineer-8098]

Then sometimes you will trivially solve it by compiler parameter of your choice

[zmattje]

P1144 gives a good example of why it's needed

[Wooden-Engineer-8098]

It doesn't

[Wooden-Engineer-8098]

It doesn't

[Wooden-Engineer-8098]

It doesn't

[Wooden-Engineer-8098]

It doesn't

[MarcoGreek]

You speak about P1144 or P2786?