Proposal Review - Expanding the Overlay [GSoC 2023] [C++ and Swift Interoperability]

Hey Everyone!

With about just a few days remaining for the proposal submission for the upcoming Google Summer of Code 2023, I would like to share my proposal for the C++ and Swift Interoperability project (specifically targeting to expanding the existing overlay on the Swift side).

I have also shared my personal thoughts about this forward vision and definitely inspired by the project which would help developers across the globe due to such a great initiative by the Swift team!

While I shared my thoughts I request my potential mentor Egor (@egor.zhdan) to look into the same and looking forward for the public open replies too!

Thanks,
Rajveer

2 Likes

Hi,

In your proposal, you describe the new CxxPriorityQueue protocol:

public protocol CxxPriorityQueue<Element> {
  associatedtype Element
  associatedtype Size: BinaryInteger
  
  func qpop() -> Element? 
}

What is the purpose of the qpop function? Why does its signature look this way? I'm specifically looking at the return type: does it match the return type of the C++ method that implements this protocol requirement?

Hey!

Although our goal is to implement the overlay for the mentioned types and containers as in my proposal, to benefit the developer in certain containers, considering the example case of CxxPriorityQueue protocol, the purpose of the qpop function is to provide the user on the Swift side to have the returned value as an optional, i.e., Element?, rather than just popping the value, and not knowing whether the queue (i.e. priority queue) is empty or not, which could lead to potential run time errors and bad error-handling.

On the C++ side, as you asked, such functionality isn't provided, in the sense, the functions (like top(), pop(), etc.) directly do the action, i.e., we would have to manually check q.empty() before popping the element, and also it doesn't return the Element after pop, hence, we first need to retrieve using q.top(), then q.pop(), while ensuring the queue size.

This was the main scenario, which made me think that why not introduce a nice way to implement those functions on the Swift side, without actually changing any internal implementation, as I am sure, Swift standard containers also have this functionality when some element is removed to return an 'optional value'.

Hope this made it more clear!