<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="">Hi Dave,</div><div class=""><br class=""></div>Let me add the following to my ideas on union(). I actually reviewed SetAlgebra quickly and I think it could conform to the guidelines better if it used the following:<div class=""><br class=""></div><div class=""><div class=""><font color="#669c35" face="Calibri" class="">// Non-mutable methods</font></div><div class=""><font face="Calibri, sans-serif" class="">let union = a.adding(b)</font><span class="Apple-tab-span" style="font-family: Calibri, sans-serif; white-space: pre;"> </span><font color="#669c35" face="Calibri" class="">// returns a ∪ c</font></div><div class=""><font face="Calibri, sans-serif" class="">let intersection = a.intersecting(b)</font><span class="Apple-tab-span" style="font-family: Calibri, sans-serif; white-space: pre;"> </span><font color="#669c35" face="Calibri" class="">// returns a ∩ c</font></div><div class=""><font face="Calibri, sans-serif" class="">let difference = a.subtracting(b)</font><span class="Apple-tab-span" style="font-family: Calibri, sans-serif; white-space: pre;"> </span><font color="#669c35" face="Calibri" class="">// returns a - b</font></div><div class=""><font face="Calibri, sans-serif" class="">let xor = a.xoring(b)</font><span class="Apple-tab-span" style="font-family: Calibri, sans-serif; white-space: pre;"> </span><font face="Calibri, sans-serif" class=""> </font><span class="Apple-tab-span" style="font-family: Calibri, sans-serif; white-space: pre;"> </span><font color="#669c35" face="Calibri" class="">// returns a △ b (a.k.a. "symmetric difference" or "exclusive or")</font></div><div style="font-family: Calibri, sans-serif;" class=""><br class=""></div><div style="font-family: Calibri, sans-serif;" class=""><font color="#669c35" class="">// Mutable methods (in-place)</font></div><div style="font-family: Calibri, sans-serif;" class="">a.add(b)</div><div style="font-family: Calibri, sans-serif;" class="">a.intersect(b)</div><div style="font-family: Calibri, sans-serif;" class="">a.subtract(b)</div><div style="font-family: Calibri, sans-serif;" class="">a.xor(b)</div><div style="font-family: Calibri, sans-serif;" class=""><br class=""></div><div class="">Thanks</div><div style="font-family: Calibri, sans-serif;" class=""><br class=""></div><div style="font-family: Calibri, sans-serif;" class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Feb 1, 2016, at 11:58 PM, Ricardo Parada <<a href="mailto:rparada@mac.com" class="">rparada@mac.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Thank you Dave for your feedback and questions. I hope I can answer your questions satisfactorily. See below. </div><div style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="">On Feb 1, 2016, at 7:30 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><span class=""></span><br class=""><span class="">Thanks for your review, Ricardo! Just one question below.</span><br class=""><span class=""></span><br class=""><span class="">on Sun Jan 31 2016, Ricardo Parada <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</span><br class=""><span class=""></span><br class=""><blockquote type="cite" class=""><span class="">Proposal link:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md</a></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">What is your evaluation of the proposal?</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">+1</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">I read the guidelines and I like them a lot in general. I think they are a very good start.<span class="Apple-converted-space"> </span></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">I have read the alternatives and disagreements in the discussion</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">threads. However, in my opinion the guidelines still stand as the</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">winner. I find it better, simpler, more concise and better looking</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">than the alternatives discussed.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">For example the ed/ ing ending for non-mutable methods. This is a</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">convention I have used in java for a long time and I found it very</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">natural in general even when the English language may not cooperate as</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">it has been discussed by others. I got used to this convention very</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">quickly many years ago in libraries I use in java.</span><br class=""></blockquote><span class=""></span><br class=""><span class="">What do you do about non-mutating versions of "split" and "union" under </span><span class="">this pattern?</span><br class=""></div></blockquote><div style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><span style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Even though the English language may not play nice with the guideline in these scenarios, I do not think it is a big problem. Let me answer to each individually.</span><div style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><b class="">split</b> </div><div style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I think one can infer mutability by its usage on the call site. For the example, if I read this code:<div class=""><br class=""></div><div class="">x.split()</div><div class=""><br class=""></div><div class="">I would infer that split() is mutating x. On the other hand if I read this:</div><div class=""><br class=""></div><div class="">let y = x.split(",")</div><div class=""><br class=""></div><div class="">I would infer that this split() method does not mutate x. This works when reading code. </div><div class=""><br class=""></div><div class="">If on the other hand I am writing the code then I would probably consult the documentation and learn whether it is mutating or not.<br class=""><br class=""><b class="">union</b> </div><div class=""><br class="">It would be similar for union(). Now, let's say that you want to have a mutable and non-mutable version of union() then we have to look for a different name or perhaps look at other alternatives mentioned. I would consider first alternatives compatible with the guidelines. For example add() and adding(). If you want to stick with union as the name then look for other alternatives discussed such as<span class="Apple-converted-space"> </span><span style="background-color: rgba(255, 255, 255, 0);" class="">unionInPlace() and union().</span></div><div class=""><br class=""></div><div class="">The guidelines are not perfect but I think they are a good start. </div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><span class="">There is only one guideline that I think is not aligned with the</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">consensus I seem to pick up from the discussions. That is the use of</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">camel case for enum cases. After reading different opinions I am now</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">leaning towards saying that Enum cases should be lower camel case</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">given that they are values. At first my opinion was the same as the</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">guideline. After reading the discussions and seeing examples I changed</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">my mind.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Is the problem being addressed significant enough to warrant a change to Swift?</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">This will bring a lot of changes when applied. I think they are a good</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">start. I don't think it should cover all cases.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">I saw the loginWithUserName(_:password:) example and alternatives:</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">login(userName:password:), etc. I don't know if this is addressed in</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">the guidelines. I don't think this example falls under the weak type</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">first argument. It would be nice to have some guidance here. I do not</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">know how to state it but I think in this case I would say</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">login(userName:password:) is better as it could be part of a family of</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">login() methods that take different parameters, i.e. credentials.</span><br class=""></blockquote><span class=""></span><br class=""><span class="">Then this is a second difference you have with the guidelines, as they</span><br class=""><span class="">are currently written to discourage first argument labels in almost all</span><br class=""><span class="">cases.</span><br class=""></div></blockquote><div class=""><br class=""></div>Thanks for pointing this out. I did not realize it until now. </div><div class=""><br class=""></div><div class="">I'll have to think about this. </div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><span class="">Does this proposal fit well with the feel and direction of Swift?</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Definitely. I find the guidelines are concise, natural and easy to get used to.<span class="Apple-converted-space"> </span></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">If you have used other languages or libraries with a similar feature,</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">how do you feel that this proposal compares to those?</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">I have used Java libraries for many years that use the ed ending for</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">non-mutable methods for example.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">I read the proposal entirely and I have read the majority of responses in the mailing list.<span class="Apple-converted-space"> </span></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">_______________________________________________</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">swift-evolution mailing list</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></blockquote><span class=""></span><br class=""><span class="">--<span class="Apple-converted-space"> </span></span><br class=""><span class="">-Dave</span><br class=""><span class=""></span><br class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span></div></blockquote></div></div></div></blockquote></div><br class=""></div></body></html>