<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><div class=""><b class="">What is your evaluation of the proposal?</b></div><div class=""><br class=""></div><div class="">I’m a big fan of guidelines like these so count me as a strong +1.</div></div><div class=""><br class=""></div><div class="">In general</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">I’m supportive of lowerCamelCase for enumerations. </li><li class="">I’m still not sure about the first argument label suggestions. Personally, I’d prefer that the first argument always <i class="">include</i> a label, but I know that is not a popular opinion.</li><li class="">I continue to believe that property access implies (or at least strongly hints) at O(1)</li></ul></div><div class=""><br class=""></div><div class="">WRT translation from ObjC to Swift a few things come to mind:</div><div class=""><ul class=""><li class="">Import things like<font face="Menlo" class="">[UIColor blueColor]</font> to Swift as <font face="Menlo" class="">UIColor.blue</font><font face="SanFranciscoText-Regular" class=""> instead of </font><font face="Menlo" class="">UIColor.blueColor()</font><font face="SanFranciscoText-Regular" class="">. That is, things that feel like static properties on a class should be imported that way. </font></li><li class="">Are singleton accessors methods or properties? <font face="Menlo" class="">[NSNotificationCenter defaultCenter]</font>imports as <font face="Menlo" class="">NSNotificationCenter.defaultCenter()</font> or <font face="Menlo" class="">NSNotificationCenter.defaultCenter</font>? </li><li class="">Group string encoding constants (and other constants like this) together in an enum or struct. I can never remember <font face="Menlo" class="">NSUTF8StringEncoding</font><font face="SanFranciscoText-Regular" class=""> since I’m always looking for StringEncoding first.</font></li></ul></div><div class=""><div class="">I know this is out of scope for this review, but I’d love for the guidelines to go even further in defining canonical Swift. What about, dare I say it, brace locations, tab-vs-spaces, how to wrap func definitions within some column width max, etc? From the sample code it appears that Apple has adopted a Swift style and it might be nice to make that public. This public style guide would not be a decree of "how one must write" Swift, but more as a "this is how the core team writes" Swift. I’m one of those developers that has no strong preference for these issues, but I really do value consistency.</div><div class=""><br class=""></div><div class=""><b class="">Is the problem being addressed significant enough to warrant a change to Swift?</b></div></div><div class=""><br class=""></div><div class="">Most definitely.</div><div class=""><br class=""></div><div class=""><div class=""><font face="SanFranciscoText-Regular" class=""><b class="">Does this proposal fit well with the feel and direction of Swift?</b></font></div></div><div class=""><br class=""></div><div class="">Yes these guidelines makes a huge difference in how the language feels. It fits perfectly with the direction of Swift.</div><div class=""><br class=""></div><div class=""><div class=""><b class="">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</b></div></div><div class=""><b class=""><br class=""></b></div><div class="">I've been a big proponent of design guides in all of the languages I’ve used: C, C++, Java, C#, Objective C, and now Swift. I really appreciate where languages make opinionated decisions on how to write idiomatic code.</div><div class=""><b class=""><br class=""></b></div><div class=""><div class=""><b class="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</b></div></div><div class=""><b class=""><br class=""></b></div><div class="">I’ve read the proposals many times and I’ve been actively following this discussion.</div><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 31, 2016, at 9:29 PM, Ricardo Parada 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=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><div class=""><div class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><p class="" style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px;"><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Proposal link:</span></font></p><blockquote class="" style="box-sizing: border-box; margin: 0px 0px 16px; padding: 0px 15px; border-left-width: 4px; border-left-style: solid; border-left-color: rgb(221, 221, 221);"><div class="" style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px;"><font class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md" class="" style="background-color: rgba(255, 255, 255, 0);">https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md</a></font></div></blockquote></div></div></div></div><div class=""><br class=""></div><div class=""><div class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><ul class="" style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px;"><li class="" style="box-sizing: border-box;"><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><b class="">What is your evaluation of the proposal?</b></span></font></li></ul><div class="">+1</div><div class=""><br class=""></div><div class="">I read the guidelines and I like them a lot in general. I think they are a very good start. </div><div class=""><br class=""></div><div class="">I have read the alternatives and disagreements in the discussion threads. However, in my opinion the guidelines still stand as the winner. I find it better, simpler, more concise and better looking than the alternatives discussed. </div><div class=""><br class=""></div><div class="">For example the <b class="">ed/ ing ending</b> for non-mutable methods. This is a convention I have used in java for a long time and I found it very natural in general even when the English language may not cooperate as it has been discussed by others. I got used to this convention very quickly many years ago in libraries I use in java. </div><div class=""><br class=""></div><div class=""><b class="">There is only one guideline that I think is not aligned with the consensus I seem to pick up from the discussions.</b> That is the use of camel case for enum cases. After reading different opinions I am now leaning towards saying that <b class="">Enum cases should be lower camel case</b> given that they are values. At first my opinion was the same as the guideline. After reading the discussions and seeing examples I changed my mind. </div><div class=""><br class=""></div><div class=""><br class=""></div><ul class="" style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px;"><li class="" style="box-sizing: border-box;"><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><b class="">Is the problem being addressed significant enough to warrant a change to Swift?</b></span></font></li></ul><div class="">This will bring a lot of changes when applied. I think they are a good start. I don't think it should cover all cases. </div><div class=""><br class=""></div><div class="">I saw the <b class="">loginWithUserName(_:password:) </b><span style="background-color: rgba(255, 255, 255, 0);" class="">example </span>and alternatives: <b class="">login(userName:password:)</b>, etc. I don't know if this is addressed in the guidelines. I don't think this example falls under the weak type first argument. It would be nice to have some guidance here. I do not know how to state it but I think in this case I would say <span style="background-color: rgba(255, 255, 255, 0);" class=""><b class="">login(userName:password:)</b> is better as it could be part of a family of login() methods that take different parameters, i.e. credentials. </span></div><div class=""><br class=""></div><ul class="" style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px;"><li class="" style="box-sizing: border-box;"><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><b class="">Does this proposal fit well with the feel and direction of Swift?</b></span></font></li></ul><div class="">Definitely. I find the guidelines are concise, natural and easy to get used to. </div><div class=""><br class=""></div><ul class="" style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px;"><li class="" style="box-sizing: border-box;"><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><b class="">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</b></span></font></li></ul><div class="">I have used Java libraries for many years that use the <b class="">ed</b> ending for non-mutable methods for example. </div><div class=""><br class=""></div><ul class="" style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px;"><li class="" style="box-sizing: border-box;"><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><b class="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</b></span></font></li></ul><div class="">I read the proposal entirely and I have read the majority of responses in the mailing list. </div></div></div></div></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>