tac
tac copied to clipboard
AcademySoftwareFoundation
Continue discussion on Swift Sub-WG [ASWF Language Interop WG] proposal
Describe the purpose of the group in no more than 4-5 sentences
The Swift working group is dedicated to providing both Swift and C/C++ interoperability between each of these languages which allows the many existing libraries across the industry to be easily extended, safer, and easier to use. While additionally empowering all software development by easy adoption of industry software through harnessing the capabilities of the Swift package manager (SPM), which makes adding a library to other projects as simple as copying a library's link and pasting it into its package dependency section.
We have currently provided Swift support of Pixar's Universal Scene Description as a proof of concept, which currently supports both Linux and Apple's operating systems.
Goals of the working group
- To work in collaboration across the ASWF in the mission to allow all of its existing projects and libraries to be consumed by other SPM projects, in the form of creating a Package.swift file at the root of every project across the ASWF, a task in which MetaverseKit proves is possible, but to do so in a modular fashion through each project's official channels.
- Through the availability of SPM plugins and other tooling to aid in bringing existing libraries to SPM.
- Creating safe, easy to use Swift APIs of these libraries, or allowing for interesting paradigms such as declarative APIs built around Swift's
@resultBuilder. - Supporting macOS, visionOS (where applicable), Linux, Wasm (where applicable), and Microsoft Windows.
Non-goals of the working group
- Existing C/C++ libraries should not be modified, or modified very little, an acceptable modification would be to add clang attributes to existing classes through the usage of macros - so long as it is done in a low-touch cross platform way, like we did for USD here.
- Rewriting existing C/C++ code into Swift.
- Supporting versions of Swift prior to Swift 5.9's C++ Interop Feature.
Deliverables
- Universal Scene Description (USD) for Swift.
- Proof of concept, MetaverseKit that will be made obsolete once ASWF projects adopt Package.swift files at the root of their repositories, if an existing ASWF project does not wish to do so we could instead provide a SPM package repository to work as a wrapper around a git submodule that fetches the project's official source code.
I've included the presentation for the proposal here for quick reference:
Let's discussing during the 3/6 on the way forward here - the voting stalled out.
Hey @jmertic! I apologize I just saw this now, had this already been discussed at the TAC meeting? I did not realize an update on the proposal would be apart of this meeting's agenda.
Thank you!
No worries @furby-tm - the TAC wants to schedule additional time to review this proposal; I'll update on when that would be.
It looks like the date was moved to April 3rd for discussion at the last tac meeting but GitHub doesn't appear to be pushing notifications for issue metadata-related changes to my inbox.
Feel free to @ ping me in a comment on this if you need anything else from me or if it gets scheduled for an upcoming tac meeting in the future, thanks!
Hi @furby-tm - there was a discussion in the TAC meeting today, and they wanted to know if there are any current ASWF projects and/or member companies who are supportive of this work and would be looking to help put resources into the work. Any insight into that? Thanks in advance.
Hello @jmertic, OpenTimelineIO is a current ASWF project that is supportive of this work.
They are looking for the following:
- Deprecate their
ObjC/Swiftin favor ofC++/Swiftbindings. - Using clang's official C++ interop to bind.
- Provide an "ergonomic" layer as needed to make the interop based binding as pretty as the existing one.
- Provide guidance on migration to users using the current bindings.
They believe moving to C++/Swift interop would solve maintenance overhead, simplify the implementation to a huge degree, and give a better path to evolving the interface.
There is also a client of theirs that uses server-side Swift, and if the Objective-C layer was removed - not only would this work help OpenTimelineIO stay modern; but it would also enable a user that isn't otherwise included.
The Swift WG would have a first work product of OpenTimelineIO, and subsequent products to be identified by TAC/TSC, we are looking at perhaps attracting a sponsor to the TAC, such as Apple.
Discussion happening on potentially aligning Rust and Swift efforts into one project, which could help look at other language bindings as well.
This proposal has shifted into now proposing Swift to be the first language sub working group to be accepted as apart of the proposed ASWF Language Interop WG.
@jmertic there is the ASWF language interop working group proposal, in addition to that one -- this proposal is for swift to become a sub working group of that working group.
Would you prefer this swift proposal be condensed into the other ASWF language interop proposal?
Whatever keeps things more streamlined and easier to manage.
Yes - if the intention is this group is part of the other one, then this should be folded into that group.