[GSoC 2023] Questions about the Scripting in Swift project

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. :arrow_heading_down:

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.

Defining an interface for any package manager to adopt

It seems the community would like to have this functionality but without the connection between swift and swiftc and swift package. So what if swift and 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.

This way swift and 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 swift and swiftc.

@stevapple touched on this when mentioning macros from the SwiftSyntax package. So this approach could just let swift and 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. :arrow_heading_down:

  • swift and swiftc could 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.

As far as syntax goes I feel the current proposed syntax mentioned here and here is fine. I think maybe something like @importPackage may be more clear than @package but that's just a style opinion.

I imagine this would be a lot of work as it'd involve changes to swift, swiftc, and 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 swift and 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!

2 Likes

The mentor for this project is @NeoNacho.

I see you've prepared quite well already and thanks @stevapple for helping out here as well!

With my organizational hat on :billed_cap: : I would suggest preparing a proposal as soon as you can and even if you'd not get more information about the project before the deadline, please do submit the proposal -- there is a chance of getting selected. We'd love to have the ability to consider your application, even if its exact details were to evolve a little bit still.

1 Like