[swift-build-dev] [swift-evolution] SE-0152: Package Manager Tools Version

Wed Feb 8 02:17:38 CST 2017

Hi,

> The review of SE-0152 "Package Manager Tools Version" begins now and runs through February 13, 2017.  The proposal is available here:
> 
> 	https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md

From the proposal:
> Not changing this API would still leave the problem of figuring out which Swift language compatibility version to interpret the manifest in. It's possible that Package.swift manifests won't be significantly affected by Swift language changes in Swift 4, and could mostly work in either language compatibility mode without changes. However, we don't know whether that will be the case, and it would be a significant risk to assume that it will be.

I really assume that the simple `Package.swift` files will be able to be compiled in swift 3 and swift 4 modes.
Do we really need this proposal now?
If we really encounter problems, we can always add it later.
So what exactly is the risk?

When we want to introduce it already now, I’d like to revisit the way the tool version is specified.

Can we _please_ not use a comment?
Comments are comments and should have no influence on how to parse the file.

By the way, in XML/HTML, the DTD/Doctype is not specified in a comment, but in a processor instruction (`<!DOCTYPE html>` vs. `<!— comment —>`).
So the XML example would more closely resemble something like `#swift(3.0)` in Swift.

Maybe the package manager could just grep for the `swiftLanguageVersion` specification?
This has to be specified by the package anyway.
We could simply specify that the swift compiler always uses the same mode for `Package.swift` and the rest of the sources,
and that the package manager obtains this version from the manifest without using the full Swift compiler.
I.e. this line would be fixed to some special syntax (`^\s*swiftLanguageVersion\s*:\s*(\d+)\s*,\s*$` or something).

— Martin