Date: Wed, 31 Aug 2022 08:30:31 -0300
On Tuesday, 30 August 2022 20:44:27 -03 Marcin Jaczewski via Std-Proposals
wrote:
> I think yes, even more I think whole C++ success was built on breakage
> like this.
> ABI break I am referring to is compatibility with C. C++ makes a break
> from it by adding
> mangling to allow linking safely with old C code without confusion.
Indeed, but C++ was never meant to be the same language as C.
What you're proposing is effectively a new language, one that may call into the
old one but not be called from it. With all the pitfalls that may turn up if
you abuse #ifdef __cplusplus or forget it.
> extern "C++20" struct A
> {
> std::_30::string x; //newer version of string for some improvements
> std::_20::vector<bool> y; //our favorite version of current vector :>
> };
>
> inline A Create(const std::string& x) //current `string` based on
> compiler option
> {
> return A{ x }; //implicit constructor from other version of `string`
> }
> And this code could be included in the header and work exactly
> the same in all available versions of C++.
I'm ok with that as written, because you have to opt-in to the new types. Or,
phrased differently, std::string is the same old and never something that is
binary-incompatible, and it's std::_30::string that must have a constructor to
copy or move from the old std::string. That comment on Create talking about
compiler options is wrong or misleading, since there's no compiler option that
would change which std::string gets used.
> //using MyTypeError = MyType; //error: name is ambiguous
> using MyTypeOld = extern "C++20" MyType;
> using MyTypeNew = extern "C++" MyType;
Obviously this doesn't compile as C++20 today, so you're going to need #ifdef
around it.
> This will allow for big codebases to "freeze" some old parts to old
> versions of C++ but still allow new compilers and new improvements in
> other parts of code while still mixing both flavors.
> cost of "freeze" of some headers will be same as writing C/C++ headers
> that work for both languages:
>
> ```
> #if __cplusplus > 202002L
> extern "C++20" {
> #endif
>
> //...
>
> #if __cplusplus > 202002L
> } // extern "C++20"
> #endif
This doesn't look correct. Either you meant extern "C++" or the ... should be
inside the #if too.
wrote:
> I think yes, even more I think whole C++ success was built on breakage
> like this.
> ABI break I am referring to is compatibility with C. C++ makes a break
> from it by adding
> mangling to allow linking safely with old C code without confusion.
Indeed, but C++ was never meant to be the same language as C.
What you're proposing is effectively a new language, one that may call into the
old one but not be called from it. With all the pitfalls that may turn up if
you abuse #ifdef __cplusplus or forget it.
> extern "C++20" struct A
> {
> std::_30::string x; //newer version of string for some improvements
> std::_20::vector<bool> y; //our favorite version of current vector :>
> };
>
> inline A Create(const std::string& x) //current `string` based on
> compiler option
> {
> return A{ x }; //implicit constructor from other version of `string`
> }
> And this code could be included in the header and work exactly
> the same in all available versions of C++.
I'm ok with that as written, because you have to opt-in to the new types. Or,
phrased differently, std::string is the same old and never something that is
binary-incompatible, and it's std::_30::string that must have a constructor to
copy or move from the old std::string. That comment on Create talking about
compiler options is wrong or misleading, since there's no compiler option that
would change which std::string gets used.
> //using MyTypeError = MyType; //error: name is ambiguous
> using MyTypeOld = extern "C++20" MyType;
> using MyTypeNew = extern "C++" MyType;
Obviously this doesn't compile as C++20 today, so you're going to need #ifdef
around it.
> This will allow for big codebases to "freeze" some old parts to old
> versions of C++ but still allow new compilers and new improvements in
> other parts of code while still mixing both flavors.
> cost of "freeze" of some headers will be same as writing C/C++ headers
> that work for both languages:
>
> ```
> #if __cplusplus > 202002L
> extern "C++20" {
> #endif
>
> //...
>
> #if __cplusplus > 202002L
> } // extern "C++20"
> #endif
This doesn't look correct. Either you meant extern "C++" or the ... should be
inside the #if too.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2022-08-31 11:30:33