<div dir="ltr"><div><div> </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:&quot;sf mono&quot;;min-height:14px"><span class="inbox-inbox-m_-6186302749948427382Apple-tab-span gmail_msg" style="white-space:pre-wrap">        </span>*  What is your evaluation of the proposal?<br></div></div></blockquote><div><br></div><div>I fully support the goals of the proposal and have a question about the implementation.</div><div><br></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:&quot;sf mono&quot;;min-height:14px"></div><div class="gmail_msg" style="margin:0px;font-size:12px;line-height:normal;font-family:&quot;sf mono&quot;"><span class="inbox-inbox-m_-6186302749948427382Apple-tab-span gmail_msg" style="white-space:pre-wrap">        </span>*  Is the problem being addressed significant enough to warrant a change to Swift?</div></div></blockquote><div><br></div><div>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><br></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:&quot;sf mono&quot;"><span class="inbox-inbox-m_-6186302749948427382Apple-tab-span gmail_msg" style="white-space:pre-wrap">        </span>*  Does this proposal fit well with the feel and direction of Swift?</div></div></blockquote><div><br></div><div>I agree that the placement of the tools version in a comment is unfortunate, but I think that it&#39;s the best way to include it in Package.swift.<br><br>I&#39;m interested in other people&#39;s thoughts on a <span style="font-family:monospace">.swift-tools-version</span> file. I&#39;m not sure I prefer it to the comment in Package.swift, but the reasons included in the proposal don&#39;t convince me the <span style="font-family:monospace">.swift-tools-version</span><span class="inbox-inbox-Apple-converted-space"> </span>shouldn&#39;t be used either.</div><div><ul><li><i>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&#39;t make again. I guess with a leading dot it&#39;s more likely to be forgotten than a non-dot-file, but not a major issue IMO.</li><li><i>Users may like to see the version in the Package.swift</i>: Probably true, though I&#39;m not sure how much of an issue it is.</li></ul><div>Are these significant problems for other people? They don&#39;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><br></div><div>The <span style="font-family:monospace">.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&#39;ll ever have to extend it? I think that, for me, is the determining factor for which format I prefer.</div></div><div><br></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:&quot;sf mono&quot;"><span class="inbox-inbox-m_-6186302749948427382Apple-tab-span gmail_msg" 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><br></div><div>The main package manager I use is CocoaPods and as far as I am aware CocoaPods doesn&#39;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&#39;t think that actually helps in this regard.</div><div><br></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:&quot;sf mono&quot;"><span class="inbox-inbox-m_-6186302749948427382Apple-tab-span gmail_msg" 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> <br></div><div>I spent some time reading through the proposal, but I lost track of the discussion pre-proposal.</div></div><div><br></div><div>- Will</div></div>