Date: Thu, 01 Sep 2022 09:51:49 -0300
On Wednesday, 31 August 2022 20:13:00 -03 Marcin Jaczewski via Std-Proposals
wrote:
> Basic idea from p2028r0 was that it will handle this case too. We do
> not tweak some std types, we break everything, user types too.
> in C++30 `myFunction` will mangle as `_Y10myFunction4Name` and will
> not link with `_Z10myFunction4Name`.
Why do you think breaking everything is a good idea?
If the already-compiled library provides only the old symbol, you get a linker
error. The problem is that the old library's header doesn't know that someone
down the line wants to use the new ABI.
Now make this three libraries:
1) one using the old ABI
2) one using the new ABI
3) one needs to use the two above
How do you mix them in the same translation unit now? Bear in mind that the
out-of-line content of each of libraries (1) and (2) is already compiled, but
you're parsing and compiling the headers of them right now.
Now make this worse by having 3 ABIs, not just two, because you opened the
door.
At a minimum, the new ABI must be opt-in everywhere. That's why I said this
can never be triggered by the same thing that selects new core language
features. Requiring that ALL the existing C++ headers mark themselves as the
old ABI is not going to happen, which leaves the marking to the new ABI.
Anyway, please try some experiments. You don't need to modify the compiler, we
already have the concept of ABI tag in GCC because of the last time we broke
ABI. The abi_tag attribute propagates somewhat.
> When a type involving an ABI tag is used as the type of a variable or return
> type of a function where that tag is not already present in the signature
> of the function, the tag is automatically applied to the variable or
> function.
But it doesn't propagate to other types that use this type as members. It
should have done that, which would have shown how much breakage that decision
was. See https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html
wrote:
> Basic idea from p2028r0 was that it will handle this case too. We do
> not tweak some std types, we break everything, user types too.
> in C++30 `myFunction` will mangle as `_Y10myFunction4Name` and will
> not link with `_Z10myFunction4Name`.
Why do you think breaking everything is a good idea?
If the already-compiled library provides only the old symbol, you get a linker
error. The problem is that the old library's header doesn't know that someone
down the line wants to use the new ABI.
Now make this three libraries:
1) one using the old ABI
2) one using the new ABI
3) one needs to use the two above
How do you mix them in the same translation unit now? Bear in mind that the
out-of-line content of each of libraries (1) and (2) is already compiled, but
you're parsing and compiling the headers of them right now.
Now make this worse by having 3 ABIs, not just two, because you opened the
door.
At a minimum, the new ABI must be opt-in everywhere. That's why I said this
can never be triggered by the same thing that selects new core language
features. Requiring that ALL the existing C++ headers mark themselves as the
old ABI is not going to happen, which leaves the marking to the new ABI.
Anyway, please try some experiments. You don't need to modify the compiler, we
already have the concept of ABI tag in GCC because of the last time we broke
ABI. The abi_tag attribute propagates somewhat.
> When a type involving an ABI tag is used as the type of a variable or return
> type of a function where that tag is not already present in the signature
> of the function, the tag is automatically applied to the variable or
> function.
But it doesn't propagate to other types that use this type as members. It
should have done that, which would have shown how much breakage that decision
was. See https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2022-09-01 12:51:52