<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><blockquote type="cite"><div class=""><br class=""></div><div class="">Is there a particular reason you're envisioning that we might need to extend the metadata for the Swift tools version?</div></blockquote><div><br></div><div>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!</div><br><blockquote type="cite"><div class="">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.</div></blockquote><div><br></div><div>Given that, I think the comment in Package.swift is almost definitely the right way to go.</div><br><blockquote type="cite"><div class="">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.</div></blockquote><div><br></div>I completely agree. Thank you for explaining!<br><br>- Will<br><br><br><blockquote type="cite"><div class="">Thanks,</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Rick</div><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 8, 2017, at 10:49 AM, Will Field-Thompson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_msg" style="word-wrap:break-word"><div class="gmail_msg" style="margin:0px;font-size:12px;line-height:normal;font-family:"sf mono";min-height:14px"><span class="gmail_msg inbox-inbox-m_-6186302749948427382Apple-tab-span" style="white-space:pre-wrap"> </span>* What is your evaluation of the proposal?<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I fully support the goals of the proposal and have a question about the implementation.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_msg" style="word-wrap:break-word"><div class="gmail_msg" style="margin:0px;font-size:12px;line-height:normal;font-family:"sf mono";min-height:14px"></div><div class="gmail_msg" style="margin:0px;font-size:12px;line-height:normal;font-family:"sf mono""><span class="gmail_msg inbox-inbox-m_-6186302749948427382Apple-tab-span" style="white-space:pre-wrap"> </span>* Is the problem being addressed significant enough to warrant a change to Swift?</div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_msg" style="word-wrap:break-word"><div class="gmail_msg" style="margin:0px;font-size:12px;line-height:normal;font-family:"sf mono""><span class="gmail_msg inbox-inbox-m_-6186302749948427382Apple-tab-span" style="white-space:pre-wrap"> </span>* Does this proposal fit well with the feel and direction of Swift?</div></div></blockquote><div class=""><br class=""></div><div class="">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.<br class=""><br class="">I'm interested in other people's thoughts on a <span style="font-family:monospace" class="">.swift-tools-version</span> 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 <span style="font-family:monospace" class="">.swift-tools-version</span><span class="inbox-inbox-Apple-converted-space"> </span>shouldn't be used either.</div><div class=""><ul class=""><li class=""><i class="">Eliminates the possibility of including either Package.swift or .swift-tools-version</i>: 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.</li><li class=""><i class="">Users may like to see the version in the Package.swift</i>: Probably true, though I'm not sure how much of an issue it is.</li></ul><div class="">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. </div><div class=""><br class=""></div><div class="">The <span style="font-family:monospace" class="">.swift-tools-version</span> 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.</div></div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_msg" style="word-wrap:break-word"><div class="gmail_msg" style="margin:0px;font-size:12px;line-height:normal;font-family:"sf mono""><span class="gmail_msg inbox-inbox-m_-6186302749948427382Apple-tab-span" style="white-space:pre-wrap"> </span>* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_msg" style="word-wrap:break-word"><div class="gmail_msg" style="margin:0px;font-size:12px;line-height:normal;font-family:"sf mono""><span class="gmail_msg inbox-inbox-m_-6186302749948427382Apple-tab-span" style="white-space:pre-wrap"> </span>* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</div></div></blockquote><div class=""> <br class=""></div><div class="">I spent some time reading through the proposal, but I lost track of the discussion pre-proposal.</div></div><div class=""><br class=""></div><div class="">- Will</div></div></div></blockquote></div><br class=""></blockquote></body></html>