Thanks for all the suggestions, we plan to discuss this later this week on the C++ Interoperability Workgroup meeting: 📅 C++ interoperability workgroup: upcoming meetings - #71 by egor.zhdan
Feel free to join!
Good point. Do you know use cases where someone wants to expose a type to C but not to C++? I wonder if we do need this granularity. Also, do we have this problem with C? The reason why we have this problem with C++ because by default we expose all the public Swift declarations we can to C++. On the other hand, @cdecl is opt-in so I am not 100% sure if we need the equivalent functionality in C.
This is also an interesting suggestion, but this would be a way bigger change. We might need to go through Swift evolution. @_expose is underscored, so we can use it to test an implementation out without having to go through the full evolution process.
I think this could work. The main concern here is the discoverability. But I think that could be mitigated via good documentation.