Possible Implementation - Expanding the Swift Overlay [GSoC 2023] [C++ and Swift Interoperability]

Development C++ interoperability
, ,
1

Hey everyone!

This is my follow up from the last post (Draft Idea), so I have implemented an example container, taking influence and coding methodology from existing implementations from the Cxx public files in the repo, I think as Egor (@egor.zhdan) suggested, one must keep grinding and try to build and work around in their codebase, I have done that, to get a hang, make my ideas and understanding stronger, and possible correct a bunch of more mistakes.

So keeping it simple, I have chosen std::deque to demonstrate the extension, as it would be little easier to interpret due to existing std::vector and correct any possible issues, compared to implementing any other container just for this example, and maybe also refer for upcoming followups:

public protocol CxxArrayDeque<Element> {
  associatedtype Element
  // Initially I thought of considering 'Int', later realized after
  // some research that 'BinaryInteger' is the universal type
  // for all integer types like 'Int', 'Int16', etc
  associatedtype Size: BinaryInteger
  
  // In my understanding, this is similar to 'std::iterator' of C++,
  // making below functions clearly straightforward
  associatedtype RawIterator: UnsafeCxxInputIterator
  where RawIterator.Pointee: Element
  
  func __findUnsafe(_ index: BinaryInteger) -> RawIterator
  
  func __endUnsafe() -> RawIterator
  
  /// Below functions would probably use the 'RawIterator' to fetch the
  /// 'begin()' and 'rbegin()' (possibly '--end()' using overload) similar to C++
  func __getFront() -> Element
  
  func __getBack() -> Element
  
  func __removeFront() -> Element
  
  func __removeBack() -> Element
}

extension CxxArrayDeque {
  
  // To get the element at certain 'index' using '[]'
  public subscript(index: any BinaryInteger) -> Element? {
    get {
      let unsafeIter = __findUnsafe(index)
      guard unsafeIter != __endUnsafe() else {
        return nil
      }
      return unsafeIter.pointee
    }
  }
}

I have put some inline comments for review, suggestions and some next steps!

Request your view point, changes and recommendations @egor.zhdan!

2

What is the purpose of these functions? I'm not sure I understand the inline comment correctly, do you intend to reimplement these functions in Swift, or are they supposed map to the C++ implementation of std::set, similarly to __findUnsafe and __endUnsafe?

If these functions are supposed to be called from clients' Swift code directly, their names shouldn't begin with an underscore. Underscored methods shouldn't be called by clients directly, and they are usually hidden from code completion.

3

@egor.zhdan I actually did not explain my complete idea for what I meant for these 'methods', sorry for that, in particular for any of the containers, I referenced in the thread, as you said, implementation on the Swift side is a possibility for the project, so in C++, all containers which involve the 'pop()', i.e., for example, 'pop_front()', 'pop_back', as in the 'deque', 'priority queue' or any other viable container, they do not return the deleted element, instead just delete it, so maybe as a feature we can implement this.

As an example for 'priority queue', possible way of few functions would be the following way:

push(element: T) - Puts an element into the priority queue.
pop() -> T? - Returns and removes the element with the highest (or lowest if ascending) priority or nil if the priority queue is empty.
peek() -> T? - Returns the element with the highest (or lowest if ascending) priority or nil if the priority queue is empty.
clear() - Removes all elements from the priority queue.

So we can do the same addition for containers similar to above context.

Regarding 'double underscores', yeah that was a mistake on my end.