Date: Sun, 8 Jun 2025 00:24:54 +0300
On Sun, 8 Jun 2025 at 00:20, Avi Kivity <avi_at_[hidden]> wrote:
> That's easy. The hard part is figuring out how to deploy such a type
> with the same name as its previous version that didn't use
> the dummy value protocol. It's a behavioral ABI break without any
> layout ABI break.
>
>
>
> This was solved already when std::string changed its ABI. The compilers shipped the standard library compiled in both modes for a while, then dropped the old mode.
Sure, but it was painful. Very painful. It's not quite that painful
for std::optional, because it's not used elsewhere in the library
internals.
But still, it's painful.
> Of course this little thing isn't worth the trouble, but libraries could use a spring cleaning anyway (like make std::deque's default constructor not allocate) and this could be added on top. Library vendors that choose not to improve, would simply not implement the feature.
I don't think the cost of the next ABI break goes to zero after the
first one, so it isn't immediately obvious to me that such a change
would necessarily open
a practical door to making more breaks. It probably would, but that
does depend on how much a nuisance the first one is and how much time
is left for the following
ones. :)
> That's easy. The hard part is figuring out how to deploy such a type
> with the same name as its previous version that didn't use
> the dummy value protocol. It's a behavioral ABI break without any
> layout ABI break.
>
>
>
> This was solved already when std::string changed its ABI. The compilers shipped the standard library compiled in both modes for a while, then dropped the old mode.
Sure, but it was painful. Very painful. It's not quite that painful
for std::optional, because it's not used elsewhere in the library
internals.
But still, it's painful.
> Of course this little thing isn't worth the trouble, but libraries could use a spring cleaning anyway (like make std::deque's default constructor not allocate) and this could be added on top. Library vendors that choose not to improve, would simply not implement the feature.
I don't think the cost of the next ABI break goes to zero after the
first one, so it isn't immediately obvious to me that such a change
would necessarily open
a practical door to making more breaks. It probably would, but that
does depend on how much a nuisance the first one is and how much time
is left for the following
ones. :)
Received on 2025-06-07 21:25:07