I think I agree with Rick. I see no benefit to making it look like this line is Swift when it's really not parsed as such. Like a doctype in HTML or a shebang line in Python, a special comment is lightweight, familiar, and does not suggest any capability it doesn't have. On Mon, Feb 6, 2017 at 17:45 Matthew Johnson via swift-evolution < [email protected]> wrote:
> > > On Feb 6, 2017, at 2:06 PM, Rick Ballard <[email protected]> wrote: > > > > Hi Matthew, > > > > The reason I was suggesting a simple DSL in a comment instead of using > Swift for that declaration is because we need to know what this value is > before we start the Swift interpreter, so that we know what Swift language > compatibility mode to run the interpreter in. I suppose that it'd be > possible to work around that; for example, we could grab the first line of > the file and run it through the Swift interpreter in the latest language > compatibility mode, assuming that a simple let statement and enum will > always compile the same way in all future versions of Swift. We'd figure > out the Swift tools version from that and then re-run the interpreter over > the entire file in the right language compatibility mode. > > > > That's some fairly magic behavior to understand, though; if it's a place > that you can write Swift code, it's non-obvious that we're only reading a > single line of it. It would also be difficult to enforce the restrictions > that we'd like on the first line; if we're using the Swift interpreter, how > do we make sure that you haven't written a more complicated expression that > might not compile in all future versions of Swift, and/or referenced any of > the version-specific PackageDescription API beyond that enum? And from an > aesthetic standpoint, I imagine that many people would be annoyed to have a > single line of Swift code at the top of the file right before any comment > header that they'd otherwise lead their file with (e.g. containing a > copyright header, author info, etc). > > > > Overall, I don't see any concrete benefit to making that first line be > Swift, and it adds new complications. This was worth considering, however, > so thanks for suggesting it! > > Hi Rick, > > Thanks for the reply. I wasn’t suggesting that you actually use the Swift > interpreter to parse this line. My idea was that if the package format > uses a top-level constant named `toolsVersion` that *must* be initialized > with a direct reference to the enum case it would be easy enough to parse > *without* using the Swift interpreter. You would just look for a line that > begins with `let toolsVersion = ToolsVersion._n_n_n`. It wouldn’t > necessarily need to be the first line. This statement has a very simple > grammar that could be parsed directly just as easily as a DSL we invent and > put in comments. > > I agree that the primary downside of this is that it would be specified > using normal Swift syntax but would not allow the full expressivity that > Swift allows (this constant must be initialized via directly specifying a > case name rather than with any value of the correct type). However, it has > the advantage of using normal Swift syntax and all the benefits derived > from that (for example, cmd-click in Xcode to see the valid values, reading > like a normal part of the package specification, etc). If the user > attempted to use an expression that is valid Swift but does not a direct > reference to one of the case names the package manager would handle that in > the same way it would handle an invalid tools version in the comment DSL. > > It’s not immediately obvious to me which approach makes the best overall > tradeoff. It seems like a topic worthy of discussion by the community, > especially since you have already listed several options and asked for > community input on the subject. Does anyone else have any thoughts on this? > > > > > - Rick > > > >> On Feb 4, 2017, at 8:28 AM, Matthew Johnson <[email protected]> > wrote: > >> > >> 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
