<div dir="ltr">On Wed, Aug 2, 2017 at 5:48 PM, Mike Sanderson <span dir="ltr">&lt;<a href="mailto:m@mikesand.com" target="_blank">m@mikesand.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 2, 2017 at 1:49 PM, Xiaodi Wu via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">...<span class=""><br><div class="gmail_quote"><span class="m_539356426819485473m_-2228558094291059079gmail-"><div dir="auto"><br></div></span><div dir="auto">This topic was reviewed extensively at the beginning of Swift Evolution. The idea is that type information does not need to be repeated in the label. Since the locale is of type Locale, “with” is preferred over “withLocale” because “withLocale: Locale” is redundant. As this has been long approved by the community, it’s not in scope to roll it back.</div></div></span></blockquote><div><br></div><div><div>Thanks to everyone who contributed to the list to make the Swift 3 API guidelines possible. I think the Swift 3 API Guidelines were a tremendous accomplishment, and I appreciate the actual beauty that can result from its sparse code. </div><div><br></div></div><div>It seems reasonable that 1 1/2 years after the proposal, more than 1 year after beta release, and after seeing the API Guidelines applied out in the world (or not) and applying them ourselves (or not), to bring up the subject again and ask if it can be improved. I think Jon gave some good examples of weaknesses that can result, and Robert gave some good suggestions.</div><div><br></div><div>Changing existing code is probably out of scope to avoid language churn--and it definitely would contradict Swift 4&#39;s goal of preserving source stability. The Great Re-Renaming? No thanks. (Thought I think The Great Renaming unfairly got the blame for later migration issues.)  Still, these messages today were substantive suggestions for how to improve Swift API naming conventions. I am re-reading the threads from Jan and Feb 2016, which seems appropriate to inform a discussion that builds on them, but it would be weird to regard those conversations as a reason to shut down any mention of the subject ever again. This seems like exactly the kind of subject that should be revisited, and could form a proposal later in the fall. </div><div><br></div><div>As someone who admires the API guidelines and how they make Swift read elegantly, I want to make them even better and easier to use. I myself think that the English language is too ungainly to support rules for a language as elegant as Swift. <span style="font-size:12.800000190734863px">So I hope we can continue to have this conversation. </span></div></div></div></div></blockquote><div><br></div><div>There is a difficult balance to strike here, to be sure. On the one hand, Jon has written a very thorough analysis of some pros and cons of Swift&#39;s API guidelines and their real-world implementation. On the other hand, while the analysis is substantive, unfortunately it does not tread new ground in terms of what has already been discussed on the list. The trade-offs and alternatives discussed today *were* studied at the time of the adoption of these guidelines, and as with any decision to do with naming, not everyone agreed with all the points. Nonetheless, a decision was made. Moreover, of Jon&#39;s five examples, one is actually not a renaming at all, one renaming was explicitly approved (with its own special rule), and the remainder are Apple APIs not subject to Swift Evolution. (I agree that `timeIntervalSince` seems to be contrary to Swift naming guidelines, but we don&#39;t get to name that API as a community.)</div><div><br></div><div>I also disagree very strongly that 1.5 years after a proposal is an appropriate time to revisit a tentpole feature of a previous release. This was a major undertaking that occupied the attention of all for a very long time. There is an interval between 1.5 years and ever again for bringing up past decisions: as idiomatic Swift grows with time, there may certainly come a time to revise guidelines laid down for Swift 3. But I strenuously disagree that Swift 5 is an acceptable timeframe for revising this effort. The most contentious disagreements on this list have been API renaming and access control modifiers; the latter is now different for each of Swift 2, 3, and 4. These efforts had costs in terms of time and energy (and likely took an emotional toll too) on participants. It is not at all &quot;weird&quot; to regard those conversations as a reason not to continue the conversation; in fact, based on that experience, I believe strongly that we would *certainly* be better off as a community by not rehashing API names.</div></div></div></div>