[cfe-dev] @encode() discrepancy between C++11 and earlier

[David Chisnall via cfe-dev]

On 12/11/2020 14:04, Nico Weber via cfe-dev wrote:
> I noticed recently that this affects Objective-C's @encode too, which 
> means it has different results based on language standard, making it 
> impossible to build part of a program with C++98 and another part with 
> C++11 (...if both parts need @encode if some common type to agree). It 
> also means @encode for types changed with that patch, which is an ABI 
> break of sorts.

As I recall, Objective-C++ doesn't specify what goes in the string for 
C++ classes (for C structs it's fairly unambiguous, and Objective-C++ 
just does something similar by analogy, there's no official 
documentation on precisely what it generates).  Is there code that 
you're aware of that parses the C++ type names?  If not, I'd suggest 
that the best thing for us to do is simply document that this encoding 
is not stable.  Any Objective-C++ code trying to parse C++ type 
declarations is going to need to be careful about unknown tokens anyway: 
something that can parse all C++98 will find a lot of unknown things in 
a C++20 program.

It would be useful if we implemented type encodings for C++ arguments in 
such a way that `NSInvocation` could correctly move-construct copies of 
the arguments to pass to another thread, but that would be an invasive 
ABI change.  I don't think it's something that you can adequately get 
out of the encoding.

David