[libcxx-commits] [libcxx] [libc++] Cooperation between `std::optional` and other standard types (PR #93672)

via libcxx-commits libcxx-commits at lists.llvm.org
Wed May 29 19:09:12 PDT 2024


EricWF wrote:

It's very cool to see this prototyped out. I had wondered what it would look like to make something like this work.
I tried cloning the branch and playing with it, but it fails to build.

However, the dependence on `__builtin_is_within_lifetime` and the need to add `launder` and other scary foot  guns throughout the code makes me rather concerned.

At the moment, I think the complexity and cons outweigh the pros, at least as an implementer. However, I have also seen people not use optional, or roll their own to get optimizations like these.


Here are a few cons of my own:

* Limited users will be able to use this because most don't use the unstable ABI or ABI v2.
* This is meant to save space, but does in negatively affect the performance otherwise? I'm thinking about how often `has_value()` appears in very hot code paths. Can you say more about the effect on code gen?

* We can't implement it correctly until every compiler we support provides `__builtin_is_within_lifetime`, which will be 2 releases after they initially implement it (without bugs).



* It constrains future changes to the ABI of other types if doing so would also break optional (potentially), and it's impossible to know if that trade off will be what we want.

* Implementing this requires either:
  1.   scribbling into unused bits of a type, or
  2.   putting the object into an invalid state, where that invalid state represents being disengaged. 
 
Either way, we're invoking undefined behavior, though in the latter case, it's library undefined behavior.
However, the library undefined behavior becomes a problem when the destructor is non-trivial,
because now we're potentially destructing an object in an invalid state, and we shouldn't do that.
  
It's also possible that the standard could choose to give semantics to a previously undefined 
state, and we couldn't implement that.
 
 

 Very cool, but this scares me a lot.



https://github.com/llvm/llvm-project/pull/93672


More information about the libcxx-commits mailing list