On 18/02/2022 10:33, Mikhail Kremniov via Boost wrote:
I wonder, what is the Boost community's opinion of std::launder? In particular, of its necessity when accessing an object that was created via placement-new in an aligned_storage. As I can see, it's used by Boost.Beast in its implementation of the variant type, but not in other parts of Boost.
Beast likely doesn't need to use it. He probably added it back when it was thought it would be needed, but CWG realised very very late on in the 17 release cycle that it was overly dangerous to existing code and they undid the need for it for the 17 release.
So, can switching from -std=c++14 to -std=c++17 be a breaking change when using Boost? The fact that Boost.Variant and Boost.Optional don't use std::launder - is it an oversight or a conscious decision?
In practice, you only need to launder const types. Otherwise you don't need to, in practice (except for corner cases, which don't matter for anything Optional or Variant or Outcome do). You also only need to launder const types if and only if you ever mutate them. So now the subset where laundering is needed is if and only if your type is const, and you mutate it. One solution is to not store your type as const, but otherwise treat it as const. Then laundering is not necessary. Another solution is don't allow mutation without enclosing type lifetime change. This is what Outcome does, and almost certainly what Variant and Optional also do. So tl;dr; I think you're safe unless it is YOU mutating const types stored in Boost objects. Or you're in a corner case, which are exceedingly rare and probably never will occur in your professional career. If anybody is about to ask me what those corner cases are, I'd suggest go ask Richard Smith. I know the only one I care about is vptr reload elision, and it's just about the only place where launder really is needed and there is no way of avoiding it. Niall