<div style="white-space:pre-wrap">My read on the API guidelines is that the mutating/non-mutating distinction is made by verbs vs. nouns. The verb itself doesn't have to "suggest" or "feel" mutating, it just has to be clearly a verb. Thus, IMO, `form` is as good a verb as any, although if we're going to return to bikeshedding I would suggest that `do` is even shorter.<br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 4, 2016 at 1:20 AM Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Looking at other languages:<div><br></div><div><ol><li>A Java like API would be: </li><ul><li>mutating func remove(T) -> Void</li><li>mutating func remove<S: SequenceType ...>(all: S) -> Void</li><li>func removed(T) -> Self</li><li>func removed<S...>(all: S) -> Self</li><li>Similarly for retain and add<br></li></ul><li>In Scala they primarily use operators, so a Scala like API would be: </li><ul><li>func -=(inout Self, T) -> Void</li><li>func -=<S: SequenceType ...>(inout Self, S) -> Void</li><li>func -(T) -> Self</li><li>func -<S...>(all: S) -> Self</li><li>Similarly for & and +<br></li></ul></ol><div><br></div>Either of these naming patterns seems better than those proposed :(.</div></div><div class="gmail_extra"></div><div class="gmail_extra"><br clear="all"><div><div> -- Howard.<br></div></div></div><div class="gmail_extra">
<br><div class="gmail_quote">On 4 April 2016 at 15:49, Thorsten Seitz via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div>I think Michel and Shawn did raise some good points here.</div><div><br></div><div>-Thorsten </div><div><br>Am 03.04.2016 um 22:27 schrieb Shawn Erickson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> What is your evaluation of the proposal?<br>
<br>
I don't like "form" as a prefix. To me there is no difference between `union` and `formUnion`: both sounds functional-style, and actually the second one perhaps a bit more to my ears. There's basically two dictionary definitions of "form":<br>
<br>
1. "bring together parts or combine to create (something)" which to me implies a new value is created, and<br>
2. "make or fashion into a certain shape or form" which would imply that the material you start with is transformed, which is apparently the intended meaning and also the reverse meaning from the above.<br>
<br>
I mean, doesn't this make sense as an API?<br>
<br>
let donut = baker.formDonut(dough) // non-mutating<br>
<br>
Perhaps instead of "form" we could use "become" as a prefix when the operation is naturally described by a noun. That would seem less ambiguous to me:<br>
<br>
a.becomeUnion(b)<br>
a.becomeIntersection(b)<br>
a.becomeSuccessor(b)<br>
<br>
It's a bit passive, but I find it fits well when the operation is a noun.<br>
<br>
And there's no way the term lends itself to non-mutating cases without things becoming nonsensical:<br>
<br>
let donut = baker.becomeDonut(dough) // non-mutating?<br></blockquote><div><br></div></div><div dir="ltr"><div class="gmail_quote"><div>I also am having difficulty coming to terms with the use of "form" (I am a native English speaker). As you note "form" can imply the creation of something from parts (more like assembling a new thing) as well as the creation of something out of a material say a of block clay (more like molding something out of an existing thing). It doesn't seem clear cut to me to imply in place mutation.</div><div><br></div><div>Additionally my eyes / brain keep seeing "from" instead of "form". This type of issue is generally true with any short word made up of the same set of letters (made worse since "from" is more common in programming then "form"). The mind quickly narrows in on a set of possible words given the letters we see and then uses context to help get the correct one and/or additional visual parsing to understand the exact ordering of letters (more energy expended). Anyway since I keep seeing "from" instead of "form" I keep going in the direction of thinking it returns something made from the two (or more) items involved (not really sure why "from" goes that direction in my head, it could also go the in place direction).</div><div><br></div><div>I would prefer something other then "form" (note I just typed "from" by mistake)... I think your suggestion of "become" has merit.</div><div><br></div><div>y.becomeUnion(x) --reads to me as--> "y become union with x"</div><div>y.formUnion(x) --read to me as--> "y from oops... y forming a union of x"</div><div>y.becomeI<span style="color:rgb(0,0,0)">ntersection</span>(x) --reads to me as--> "y become intersection with x"</div><div></div><div>y.form<span style="color:rgb(0,0,0)"><span style="color:rgb(0,0,0)">I</span><span style="color:rgb(0,0,0)">ntersection</span></span>(x) --read to me as--> "y from oops... y forming an intersection with x"<br></div><div><br></div><div>In the "forming" situations it – to me – is ambiguous on if that is in place or not. To me it implies more of giving something new back.</div><div><span style="color:rgb(0,0,0)"><br></span></div><div>I am -1 on "form" aspect of this proposal. ...of course things are learnable as long as things are fairly consistent and not to far out of the norm for typical language use. Personally I don't see "form" as that typical in English.</div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><div>-Shawn</div><div><br></div><div><br></div></div></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>