I am interested in working on pitching an attribute like @expose that was proposed in this thread. We would like to adopt it for Swift and C++ interop, to control which Swift APIs get exposed to C++ (APIs would have to be explicitly annotated with @expose). I think it could potentially act as a replacement for @_cdecl as well.
So far I have thought about the following behavior for this attribute:
-
@expose- tells the compiler that this declaration is exposed to a foreign language interface (C/C++/Objective-C++, in one unified header). Most likely when applied to something like a struct, it will expose all its public members too. Note that in this case the Swift declaration will still use the underlying Swift ABI. -
@expose(c++, name)- tells the compiler that this declaration is exposed to a foreign language interface. In the generated C++ interface, this declaration will be renamed with the specified name. -
@expose(c, name, convention: cdecl)- equivalent to today's@_cdecl(name)essentially.
I am most likely going to work on a formal evolution pitch and proposal for @expose sometime this year, but I'm interested in getting feedback before then as well.