C++ Interop workgroup meeting notes (Feb 23rd 2022)

This post contains the meeting notes (summarized from the meeting transcript) from the first Swift and C++ interoperability workgroup sync-up meeting that took place on the 23rd of February.

Attendees: compnerd, Alex_L, CaelanMacArthur, richard, plotfi, zoecarver, cabmeurer, 0x41c, adlere, bro4all, degoo, Dave_Lee, atierian, NuriAmari, Adrian_Prantl, egor.zhdan

Action Items

  • Alex_L is going to schedule additional meetings for new contributors.
  • zoecarver is going to check if we can allow the use of 'C++ Interop' label on Github PRs for all contributors.
  • compnerd is planning to follow-up on the issue of swift driver linking with C++ runtime.
  • cabmeurer and 0x41c are going to start working on some specific documentation pages.
  • Alex_L will follow-up on setting up a website page on the Swift.org website for the Swift and C++ interoperability project.

Discussion

High-level status: forward interop usable for std::vector and std::string. Reverse interop is in development.

New contributors:

Documentation:

  • Existing manifesto document is somewhat outdated.
  • Planning to have 3 new high level documentation pages: vision, status and roadmap.
  • plotfi: Can we have a subsection of the roadmap that talks about mixed language mode (Objective-C++).
  • zoecarver: Yes, that's a good idea. We should also be transparent about differences between platform support.
  • richard: It would be good to have documentation on how to get started with C++ packages in SwiftPM. It would be good to have documentation for how to get started and use C++ interop with SwiftPM.
  • compnerd: At this point there are some blocking issues preventing us from using C++ interop with SwiftPM: Swift driver doesn’t support linking c++ runtime. compnerd has a patch to resolve this, will put it up.
  • compnerd: Another issue for SwiftPM: defining flags for a system library, especially important outside of Darwin.
  • atierian: We should have a getting started guide for C++ interop as well.
  • zoecarver: Okay, so a couple people said they wanted to work on documentation. Is that something interesting to any of those people?
  • cabmeurer : That sounds interesting, I'd be happy to work on that.
  • zoecarver: Another thing to document is getting started with standard library and standard library types.
  • 0x41c: I would like to be a part of the effort to help with that.
  • richard: I also have to help with the docs, if my experience with working with swift package manager can help here. Would need some guidance.
  • Alex_L: Suggested to mention it in the vision first, and then see what’s left to do in SwiftPM, and then start documenting how to get started with interop and SwiftPM.
  • Alex_L: Another documentation suggestion: Naming convention for renamed declarations. E.g. bro4all‘s PR related to getters and setters.
  • 0x41c: I can help with that as well.

Website:

  • Suggested to have a landing page on the website to describe the Swift and C++ interop project, that points to the different documentation docs.
  • atierian: Are you thinking about a page under the open-source efforts section?
  • Alex_L: Yes
  • compnerd: Given the rapidly-evolving nature of this project , would it make sense to do a wiki.
  • zoecarver: we could have a table of contents page with links to Github docs.
  • Alex_L: Yes, something like that works. Will follow-up.

Discussion related to https://forums.swift.org/t/disambiguating-const-non-const-overloaded-class-methods/55263:
Started discussing the idea of adding Mutating suffix to disambiguate methods. compnerd brought up the point of a function that has mutating in its name already, how do you deal with the conflict? The workgroup thought that teaching Swift how to potentially overload based on mutating is interesting. compnerd mentioned that renaming can break Swift’s fluidity and become somewhat jarring. atierian brought up a point against renaming imported method - the Swift developers consuming C++ code would need to understand nuances of const rules in C++. richard mentioned that it might not be bad if we use another name for non-const method, as developers might want to create an overlay for the C++ library anyway, and they can tweak the API there.

10 Likes