Hello! My name is Ty and I'm a student at the University of London. I've used Swift before in a few personal projects and some open-source applications. I'm excited at the prospect of actually contributing to the language itself as it's something I would've never thought of prior to hearing about Google Summer of Code. I understand I'm late to the party but I hope to still submit a proposal prior to the deadline.
I'm interested in the Scripting in Swift project but I could use some help on guidance in terms of design decisions. I have a proposal drafted but as I've learned more about the details of this project I'm a bit unsure which direction to head in.
I contacted @stevapple and he helped me out and filled me in on what he worked on during GSoC 2021 and his thoughts on the continuation of the project (thank you again YR). I've also read through the various pitches and proposals related to the project. Specifically. ︎
- SwiftPM support for Swift scripts
- [Pitch] SwiftPM support for Swift scripts (revision)
- Pre-Pitch: `@package` argument syntax
As I understand there are already tools such as
swift-sh that do a good job at adding package functionality to a Swift script. But I understand why it may not be ideal. It doesn't have any direct integration with the Swift CLI nor support for syntax validation or highlighting.
My initial thought was to build a tool similar to
swift-sh using a comment syntax but I eventually realized it'd be difficult to tie it into the Swift REPL and concluded I'd just be reinventing the wheel at that point.
So, I see that there's a push for baking a syntax to import packages directly into Swift. But this is where I get a bit stumped as I'm not sure what the community would prefer as far as implementation goes.
In the comments of the proposals I've read, some members of the community seem to be cautious about adding new syntax to the compiler because it'd require communication with the Swift package manager, which is understandable. @stevapple worked on this and was able to deliver a proof of concept.
It seems the community would like to have this functionality but without the connection between
swift package. So what if
swiftc looked for package dependencies but, instead of directly calling
swift package, just put out an interface that any package manager could implement and then use to resolve dependencies.
swiftc would just be looking for package dependencies and then passing them off without knowing what tool would resolve them. As well, this way a new script-specific tool wouldn't necessarily be required as this logic could just be baked into
@stevapple touched on this when mentioning macros from the SwiftSyntax package. So this approach could just let
swiftc define an interface that any other package manager (including
swift package) could implement.
There are a few cons to this system that I can think of. ︎
swiftccould support the newly introduced syntax (#/@package or something similar) but wouldn't be able to verify dependencies are actually installed. Unless there was some kind of callback that package managers could use to provide verification that dependencies are resolved. So error reporting would likely be kind of limited. So it'd be a step up from comments but still limited in functionality.
- It could be too flexible and possibly introduce bad coding practices and errors into codebases. i.e. randomly placing package dependencies throughout a project.
I imagine this would be a lot of work as it'd involve changes to
swift package so I'm not sure it'd be possible to finish this by the end of the summer. However, I could continue building @stevapple's proof of concept and work on implementing the aforementioned changes. Perhaps, just focusing on changes to
swiftc first and then working on how
swift package would accept the interface.
I've read some of the posts on SwiftSyntax but I'm still a bit confused. Packages that make use of SwiftSyntax have to be included as a run-script of some sort right? And it's not currently in the Swift toolchain but it will be soon? Does this mean that a tool could be built based on SwiftSyntax that could be included in the Swift toolchain that could handle the aforementioned logic? Or is SwiftSyntax only used to make extensions?
Any thoughts on any part of this would be greatly appreciated!