<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="">Actually the same method name add can be applied to both single and multiple elements, since it should be impossible for Element to be a sequence of itself the following should never be ambiguous:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func add(_ element:Element)</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func add<S:SequenceType where S.Generator.Element = Element)(_ elementsOf:S)</font></div><div class=""><br class=""></div><div class="">So there’s actually no need for a second name. Personally it’s a bug bear of mine about Arrays with their append() and appendContentsOf() methods; both are append actions, the only difference is what you’re appending. If clarity is an issue then the external label could be required in the sequence case but personally I don’t think it requires the extra clarity as long as you know what you’re passing into the method.</div><div class=""><br class=""></div><div class="">Using your terminology I’d therefore just stick to add/union, remove/removing and intersect/intersection, i.e- no special cases for xs.</div><br class=""><div><blockquote type="cite" class=""><div class="">On 5 Feb 2016, at 11:36, Thorsten Seitz 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=""><span class=""></span></div><div class=""><div class=""></div><div class="">+1 for keeping "union" </div><div class=""><br class=""></div><div class="">When using "add" for mutating set union how would we express adding a single element?</div><div class=""><br class=""></div><div class="">Tossing about some ideas, where x is a single element and xs is a set and foo()/fooed() is the mutating/nonmutating pair for an operation:</div><div class=""><br class=""></div><div class="">Using addAll and removeAll for set operands:</div><div class=""><br class=""></div><div class="">- add(x)/adding(x), addAll(xs)/union(xs)</div><div class="">- remove(x)/removing(x), removeAll(xs)/removingAll(xs)</div><div class="">- intersect(xs)/intersection(xs)</div><div class=""><br class=""></div><div class="">or an alternative which keeps closer to set algebra:</div><div class=""><br class=""></div><div class="">- insert(x)/inserting(x), add(xs)/union(xs)</div><div class="">- <span style="background-color: rgba(255, 255, 255, 0);" class="">remove(x)/removing(x), subtract(xs)/difference(xs)</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">- intersect(xs)/intersection(xs)</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class="">The latter one retains a verb/noun symmetry for the set algebra operations which I find quite nice.</div><div class=""><br class=""></div><div class="">-Thorsten </div><div class=""><br class="">Am 02.02.2016 um 22:02 schrieb Ricardo Parada via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div class=""><span class=""></span></div><div class=""><div class="">You can still have <b class="">union() </b>instead of or in addition to <b class="">adding()</b> and the API would still conform based on the following guideline:</div><div class=""><br class=""></div><div class=""><ul style="box-sizing: border-box; margin: 1em 0px; padding: 0px 0px 0px 40px; list-style-position: initial; list-style-image: initial;" class=""><li style="box-sizing: border-box; margin: 0px; padding: 0px;" class=""><p style="box-sizing: border-box; margin: 0px 0px 1.5em; padding: 0px;" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Uses of <strong style="box-sizing: border-box;" class="">nonmutating methods should read as noun phrases</strong> when possible, e.g. <code class="highlighter-rouge" style="box-sizing: border-box; padding: 3px 8px; border: 1px solid rgb(229, 229, 229);">x.distanceTo(y)</code>, <code class="highlighter-rouge" style="box-sizing: border-box; padding: 3px 8px; border: 1px solid rgb(229, 229, 229);">i.successor()</code>.</span></p></li></ul></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">And union is the name of the operation, in other words, it is a noun. </span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">However the mutable method would have to be <b class="">add()</b> which I personally like since we are adding elements to the receiver. </span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">The subtract() / subtracting() could be called remove() / removing() so that it does not sound like an arithmetic operation. </span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><br class="">On Feb 2, 2016, at 11:59 AM, 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" class=""><div class=""><span class=""></span><br class=""><span class="">on Tue Feb 02 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="">Hi Dave,</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Let me add the following to my ideas on union(). I actually reviewed</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">SetAlgebra quickly and I think it could conform to the guidelines</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">better if it used the following:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">// Non-mutable methods</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">let union = a.adding(b) // returns a ∪ c</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">let intersection = a.intersecting(b) // returns a ∩ c</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">let difference = a.subtracting(b) // returns a - b</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">let xor = a.xoring(b) // returns a △ b (a.k.a. "symmetric difference"</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">or "exclusive or")</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">// Mutable methods (in-place)</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">a.add(b)</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">a.intersect(b)</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">a.subtract(b)</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">a.xor(b)</span><br class=""></blockquote><span class=""></span><br class=""><span class="">OK. You may think this is just me, but a set abstraction that doesn't</span><br class=""><span class="">include an operation called "union" is really hard for me to accept.</span><br class=""><span class="">It's a basic part of the set abstraction.</span><br class=""><span class=""></span><br class=""><blockquote type="cite" class=""><span class="">Thanks</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">On Feb 1, 2016, at 11:58 PM, Ricardo Parada</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><<a href="mailto:rparada@mac.com" class="">rparada@mac.com</a>> wrote:</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Thank you Dave for your feedback and questions. I hope I can answer</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">your questions satisfactorily. See below.</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">On Feb 1, 2016, at 7:30 PM, Dave Abrahams via swift-evolution</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>>></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">wrote:</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Thanks for your review, Ricardo! Just one question below.</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">on Sun Jan 31 2016, Ricardo Parada</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>>></span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">wrote:</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Proposal link:</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><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></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><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></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">What is your evaluation of the proposal?</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">+1</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">I read the guidelines and I like them a lot in general. I think</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">they are a very good start.</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">I have read the alternatives and disagreements in the discussion</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">threads. However, in my opinion the guidelines still stand as the</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">winner. I find it better, simpler, more concise and better looking</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">than the alternatives discussed.</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">For example the ed/ ing ending for non-mutable methods. This is a</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><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></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">natural in general even when the English language may not cooperate as</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">it has been discussed by others. I got used to this convention very</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">quickly many years ago in libraries I use in java.</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">What do you do about non-mutating versions of "split" and "union"</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">under this pattern?</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Even though the English language may not play nice with the</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">guideline in these scenarios, I do not think it is a big</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">problem. Let me answer to each individually.</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">split </span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">I think one can infer mutability by its usage on the call site. For</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">the example, if I read this code:</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">x.split()</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">I would infer that split() is mutating x. On the other hand if I read this:</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">let y = x.split(",")</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">I would infer that this split() method does not mutate x. This works</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">when reading code.</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">If on the other hand I am writing the code then I would probably</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">consult the documentation and learn whether it is mutating or not.</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">union </span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">It would be similar for union(). Now, let's say that you want to</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">have a mutable and non-mutable version of union() then we have to</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">look for a different name or perhaps look at other alternatives</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">mentioned. I would consider first alternatives compatible with the</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">guidelines. For example add() and adding(). If you want to stick</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">with union as the name then look for other alternatives discussed</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">such as unionInPlace() and union().</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">The guidelines are not perfect but I think they are a good start. </span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" 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></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><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></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">camel case for enum cases. After reading different opinions I am now</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">leaning towards saying that Enum cases should be lower camel case</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><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></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">guideline. After reading the discussions and seeing examples I changed</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">my mind.</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Is the problem being addressed significant enough to warrant a change to Swift?</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><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></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">start. I don't think it should cover all cases.</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">I saw the loginWithUserName(_:password:) example and alternatives:</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">login(userName:password:), etc. I don't know if this is addressed in</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">the guidelines. I don't think this example falls under the weak type</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><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></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><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></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><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></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">login() methods that take different parameters, i.e. credentials.</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Then this is a second difference you have with the guidelines, as they</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">are currently written to discourage first argument labels in almost all</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">cases.</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Thanks for pointing this out. I did not realize it until now. </span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">I'll have to think about this. </span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Does this proposal fit well with the feel and direction of Swift?</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Definitely. I find the guidelines are concise, natural and easy to get used to. </span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">If you have used other languages or libraries with a similar feature,</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">how do you feel that this proposal compares to those?</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><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></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">non-mutable methods for example.</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">How much effort did you put into your review? A glance, a quick</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">reading, or an in-depth study?</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">I read the proposal entirely and I have read the majority of</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">responses in the mailing list.</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">_______________________________________________</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">swift-evolution mailing list</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><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></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><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></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">-- </span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">-Dave</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">_______________________________________________</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">swift-evolution mailing list</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>></span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><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></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><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></blockquote></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><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><br class=""></div></blockquote></div></div></blockquote><blockquote type="cite" class=""><div 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><br class=""></div></blockquote></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>