Itβs clear that a lot of work has gone into identifying and evaluating several different approaches. Thank you for doing the hard work here!
I think I might have one additional alternative to consider. I like the idea of using Package.swift to specify the tools version, but I think the disadvantages of using a DSL in a comment is less than ideal. Is there a way we can design this to rely on normal Swift syntax? For example, what if we required Package.swift to include a line whose first non-whitespace character is the following (possibly allowing trailing comments): let toolsVersion = ToolsVersion._3_1 This would be supported by a ToolsVersion enum to which we add a new case with each new version of the tools. If no such declaration is found it will be it would be considered to be 3.0.0 just as with the comment approach. Is there any reason why using a comment DSL is preferable to something like this? > On Feb 3, 2017, at 3:03 PM, Rick Ballard via swift-build-dev > <[email protected]> wrote: > > As part of Swift source compatibility, the Swift compiler added a new flag > for controlling what Swift language version should be used to compile with. > Currently there is no good way to specify this for Swift packages. We've got > a proposal ready that provides a mechanism for controlling this. I'd > appreciate any feedback the community would like addressed before this goes > through evolution review. > > The Swift language version support proposal can be viewed and commented on at > https://github.com/rballard/swift-evolution/pull/2/files > > Additionally, we are proposing to introduce a "Swift minimum tools version" > mechanism for Swift packages. This mechanism will allow us to evolve the > package manager β adding new API, and doing a one-time revision of our > existing API for Swift 4 β without breaking the package ecosystem. It will > also manage the Swift 3β>4 language transition for Package.swift files > themselves. This is a pretty lengthy proposal, but I'd appreciate any > important feedback before this goes to evolution review. There is also one > decision left to make before this proposal is final; I lay out several > possibilities for how we could store the "Swift tools version". I'd > appreciate feedback on which of the possibilities we should pick before I > bring this to review. > > The Swift tools version support proposal can be viewed and commented on at > https://github.com/rballard/swift-evolution/pull/1/files > > Absent any serious feedback which requires us to make major revisions, I'm > expecting to bring both of these to Swift evolution review early next week. > > Thank you, > > - Rick > > _______________________________________________ > swift-build-dev mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-build-dev _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
