This post contains the summarised meeting notes from the Swift and C++ interoperability workgroup sync-up meeting from the 28th of February.
zoecarver to open up a JIRA issue to track importing overload sets for
constand value category overloads and to pick the right one at the SIL level.
- Alex_L to start google doc for vision and status docs.
- zoecarver / Alex_L to review compnerd’s Swift driver patch.
Continuation of discussion related to Disambiguating const/non-const overloaded class methods that started in the previous previous meeting (C++ Interop workgroup meeting notes (Feb 23rd 2022)):
Compnerd brought up the issue of overloading that could happen on lvalue/rvalue
this, in addition to
constoverloads for member functions. Would we want to rename them too (e.g. funcAmpersand)?
zoecarver: for now we don’t have representation for rvalue methods (except maybe inout parameter). However, the tri-state between regular,
- compnerd: handling this overloading ambiguity using a specific naming scheme could be problematic, especially as C++ evolves in the future.
Alex_L: users could rename specific overloads to resolve the ambiguities on the Swift side using attributes. Also, we should differentiate
constas it’s more pressing.
constissue isn’t more pressing as we have a solution now. We need to find a good long-term solution.
constis more broadly used, and we want to have a good story for it, to make it easy to use from Swift.
- compnerd: we need a solution that scales across all 3 overloads. What if we import them as an overload set to Swift? We then would pick the overload based on C++’s ordering of these overloads.
- zoecarver: Do we need an escape hatch?
compnerd: We ought to fall back to C++ because C++ has a very nice escape hatch - explicitly cast your types to actually handle this. So if you need to go from
const, you can do something like
var _x = xand call the method on
- zoecarver: How do you do that with value categories?
- compnerd: The value categories will require some type of wrapper.
- zoecarver: would be nice if we could avoid baking C++’s value category semantics into Swift’s type system, as this doesn’t mesh well with Swift’s declarative scoped approach.
compnerd: not sure I understand about making
constas part of the type system.
- zoecarver: that applies more to the value categories now having to be modelled by the type system.
- compnerd: if we don't introduce that into the type system, where else could we actually store that in a way that's accessible to the user? Because that's ultimately what escape hatch needs.
- zoecarver: right. We could do it without types by naming or by declaring a new scope for a value and then using it as appropriate. I guess that’s rarely what you’ll need to do.
- compnerd: agreed. Important to keep in mind that escape hatch is the rare case. Important to keep the common case nice and easy and make it possible to do the more complex cases with a little bit more effort.
- zoecarver: I guess if we have an overload set the compiler will be smart enough to pick the overload based on the value context. I like that.
Alex_L: if we’re going to differentiate overloads for member functions based on
this, should the same principles be also applied for regular functions which take in a
- compnerd and zoecarver discussed how this problem applies in generic context.
Alex_L: my question was more about the simple case with a T & and the other with T&& or T and
const T &where T is a specific type.
- compnerd: I think that case is simpler and we should apply the overload resolution set. Also naming stops working here as you could have multiple parameters with this issue.
- Alex_L: you could use argument labels to differentiate the overload.
zoecarver: you don’t even have to do that, as Swift should allow us to differentiate between
Tthat we want to move, and a mutable reference.
- compnerd and zoecarver discussed how expensive it could be for the type-checker to pick the right overload (for methods). Zoecarver thought that it wouldn’t be expensive as you could always assume that any overload would work, it’s just that we might need to do an extra copy. We could then pick the right overload after type-checking, e.g. using an additional pass. We should be able to make this assumption as we could always pick some method. This would work even for moves, and we wouldn’t need to express it with additional syntax at the source level.
- Alex_L: That’s a good idea, and should work. Could you summarise it and add a JIRA item to track this?
- zoecarver: yes, I can do that, and I might do a write-up that I can send to this group too with the details.
- CONCLUSION: The workgroup’s recommendation here is to pivot to importing an overload set using the original method name, and not to rename non-
constmethods. The right overload for
const, or lvalue/rvalue would then be chosen at the SIL level.
Discussion related to documentation:
- Alex_L: Planning to create a google doc for vision and status that we can put together and post on Github.
- zoecarver: let’s revisit what people are working on related to the documentation.
- 0x41c: should I document how to bridge C++ standard library into Swift?
- zoecarver: Yeah, talking about bringing the standard library is really interesting. You could talk about maybe bridging standard vector and you can talk about, like, how you can extend standard vector to, you know, conform to random access collection and then use it.
- plotfi: I wanted to mention with the documentation thing, I have a good repo that I set up almost a year ago that we've been just sort of adding code to and experimenting with things like a sample interop app (GitHub - plotfi/cxx-interop-test: Small test app for C++ Interop with Swift.).
- 0x41c: that repo is valuable, I was able to setup a simple project for myself to try with it.
- bro4all suggested that 0x41c and bro4all talk about documentation for the getter and setter patch.
- zoecarver: suggested putting these discussions, on the forums between this workgroup, to let others observe to understand the documentation changes that are happening.
- zoecarver talked about the different types of the documentation we want - ranging from high level user guides to specific details on the bridging names.
- Alex_L: good point. We can approach it in a couple of ways. Could have one large user guide document that’s separated out into specific sections to cover different topics. Or could have multiple documents describing each topic in depth. We could also create a sample Swift PM C++ interop repo on github, I will need to check how feasible that is.
- compnerd: that reminds me that I have a patch for Swift driver to help us support interop better.
- zoecarver will take a look.
- Alex_L: looks like documentation is a topic that we should revisit at every sync-up, so I will add it to the agenda every week.