> > Is there a particular reason you're envisioning that we might need to extend > the metadata for the Swift tools version?
I can't think of any reason myself, I just noticed the escape hatch and was wondering if there were any planned uses for it! > We've left ourself an escape hatch in case we ever do need to, where anything > after a ';' character in the tools version comment will be ignored for now, > but I'm not expecting that we'll ever need to use that escape hatch. The > Swift tools version itself needs to be stored in a special way since it > dictates how we'll interpret the manifest, but once we've determined that, > all other data should be able to be stored as Swift code in the manifest as > per usual. Given that, I think the comment in Package.swift is almost definitely the right way to go. > If you can think of some good reasons why we'd actually need this > extensibility, please do suggest them. Otherwise I'd hope that we wouldn't > need to choose a less convenient mechanism here for the sake of more > convenient extensibility that will likely never be used. I completely agree. Thank you for explaining! - Will > Thanks, > > - Rick > >>> On Feb 8, 2017, at 10:49 AM, Will Field-Thompson via swift-evolution >>> <[email protected]> wrote: >>> >>> >>> * What is your evaluation of the proposal? >> >> I fully support the goals of the proposal and have a question about the >> implementation. >> >>> >>> * Is the problem being addressed significant enough to warrant a >>> change to Swift? >> >> Yep. It provides a good way to evolve the API, and putting it in place for >> Swift 3.1 gives us the freedom to evolve the API as (or if) needed for Swift >> 4. >> >>> * Does this proposal fit well with the feel and direction of Swift? >> >> I agree that the placement of the tools version in a comment is unfortunate, >> but I think that it's the best way to include it in Package.swift. >> >> I'm interested in other people's thoughts on a .swift-tools-version file. >> I'm not sure I prefer it to the comment in Package.swift, but the reasons >> included in the proposal don't convince me the .swift-tools-version >> shouldn't be used either. >> Eliminates the possibility of including either Package.swift or >> .swift-tools-version: Seems like exactly the kind of mistake you make once >> and then don't make again. I guess with a leading dot it's more likely to be >> forgotten than a non-dot-file, but not a major issue IMO. >> Users may like to see the version in the Package.swift: Probably true, >> though I'm not sure how much of an issue it is. >> Are these significant problems for other people? They don't seem that way to >> me, but I may not represent the majority here as my work is in iOS dev and >> the only time I get to use swiftpm is for side projects. >> >> The .swift-tools-version has the advantage that it is extendable in a >> prettier (i.e. easier to read and easier to diff for VCS purposes) way than >> the semicolon-separated syntax from the proposal. How likely is it that >> we'll ever have to extend it? I think that, for me, is the determining >> factor for which format I prefer. >> >>> * If you have used other languages or libraries with a similar >>> feature, how do you feel that this proposal compares to those? >> >> The main package manager I use is CocoaPods and as far as I am aware >> CocoaPods doesn't allow you to specify the tools version in the Podfile. >> This did cause some (albeit minimal) pain on transition to CocoaPods 1.0. I >> think Podfile.lock records the version of CocoaPods, but I don't think that >> actually helps in this regard. >> >>> * How much effort did you put into your review? A glance, a quick >>> reading, or an in-depth study? >> >> I spent some time reading through the proposal, but I lost track of the >> discussion pre-proposal. >> >> - Will >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
