Some Thoughts on C++ Interoperability

Development C++ interoperability
1

     Splitting this out from '[Manifesto] Interoperability between Swift and C++' under 'Discussion' under 'Evolution' and cross-posting it from this post on that thread after it didn't get noticed:

      Rather belatedly, here are some things I thought might — well? — need to get taken into account, kept in mind, and/or tracked, at least at some point, sorted roughly by the section(s) of the manifesto they pertain to:

  • 'Differences in move semantics between C++ and Swift' and related sections:
    • Recent attempts to propose 'move relocation' for C++:
      • P1029 , move = bitcopies (previously move = relocates, née SG14 [[move_relocates]]) by Niall Douglas (GitHub tracking issue at cplusplus/papers#359)
      • P1144 , Object relocation in terms of move plus destroy by Arthur O'Dwyer (GitHub tracking issue at cplusplus/papers#43)
  • 'Templates :'
    • Could the problems here get mitigated (on the C++ side) by, for each unspecialized template, using a type-erasing polymorphic wrapper to implement a handle bundling all of the concrete instantiations of that same unspecialized template's defaulted or custom, explicit or implicit specializations together?
  • 'Exceptions :'
    • Standards proposals for introducing 'static exceptions' into C++, as well as one other, related paper:
      • P0709 , Zero-overhead deterministic exceptions: Throwing values by Herb Sutter (GitHub tracking issue at cplusplus/papers#310 )
      • P1028, SG14 status_code and standard error object (previously SG14 status_code and standard error object for P0709 Zero-overhead deterministic exceptions,) by Niall Douglas (GitHub tracking issue at cplusplus/papers#405)
      • P1095R0 (also ISO C WG14 N2289,) P1095R0/N2289: Zero overhead deterministic failure — A unified mechanism for C and C++ by Niall Douglas (GitHub tracking issue at cplusplus/papers#319 )
      • P2170, Feedback on implementing the proposed std::error type by Charles Salvia (GitHub tracking issue at cplusplus/papers#879)
      • Maaay-be P2232, Zero-Overhead Deterministic Exceptions: Catching Values by Emil Dotchevski (GitHub tracking issue at cplusplus/papers#965)

Also, when it comes to text handling, there might be some additional work WG21's SG16 for text and Unicode could do on the C++ side to make things easier for interoperating with Swift and other languages which you could coordinate with them.

Finally, also, could type-erasing polymorphic wrappers on the C++ side also help with protocols? (In the sense — or sense adjacent to — 'run-time concepts' and P1900, namely sections 3.1 and 5, though of course nothing's come of that/those line(s) of thought in terms of WG21 standards proposals just yet.)

2

     Some recent additional thoughts here:

  • There's a (currently long inactive) C++ WG21 proposal P0468, 'An Intrusive Smart Pointer' by Isabella Muerte (cplusplus/papers issue #324,) which, if progressed forward furhter and later approved for standardization, would add a 'retain_ptr' type to the C++ standard library. I might ask if this facility could help with ARC interoperability, but that's probably handled on Swift's side, not C++'s?

  • Can and will Swift executors have any interoperability with C++ P2300 sender-/receiver-based executors? (cplusplus/papers issue #1054)

  • The C++ standards committee has also been looking into trying to solve issues in the language regarding program object lifetime over at least the last standardization cycle or two. Some activity in this space includes:

    • P1179, ' Lifetime safety: Preventing common dangling' by Herb Sutter (cplusplus/papers issue #312)
    • P0936, 'Bind Returned/Initialized Objects to the
      Lifetime of Parameters,' by Richard Smith and Nicolai Josuttis
    • Non-GitHub standardization issue CWG2669, ' Lifetime extension for aggregate initialization' (Also has a cplusplus/papers GitHub issue, #1511

    This is by no means an exhaustive list. (There may be some newer papers, but I can't find them at the moment; sorry.) Might any of this work be any help with at least some of the difficulties around the differences between Swift's and C++'s object lifetime rules?

3

Any sort of standardization of things like this should make it easier for Swift to automatically do the right thing during import.

I think these concepts are probably just a little too different to bridge automatically.

I don't have high hopes for any of this, but yes, any information that gets encoded in the source is something we can use to provide a safer import experience.

1 Like