<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="">I would like to warn agains attempts to use ‘grammar’ as justification for API design. The problem is that language is not just about following some particular rules of grammar. Language is all about convention, and grammar is essentially an optimisation technique that allows us to use convention more efficiently. Still, grammar is only one of the tools we have when communicating — the actual rules of language use are much more complicated. I am not sure that every mathematician will immediately understand what you mean by ‘uniting two sets’ — because nobody uses that particular terminology. Now, ‘creating a union of two sets’ is a perfectly clear concept. Its not the grammatical form that conveys the meaning but what we conventionally associate with that particular form in that particular context. Union, intersection etc. are conventionally non-mutating concepts. All proposals for mutating concepts I have seen so far are not semantically transparent, because they do not follow the commonly accepted convention. The most appropriate names for those APIs I can come put with is something like<div class=""><br class=""></div><div class="">func replaceWithUnion(with: Self)</div><div class="">func replaceWithIntersection(with: Self)</div><div class=""><br class=""></div><div class="">or maybe</div><div class=""><br class=""></div><div class="">func unionUpdate(with: Self)</div><div class="">func intersectionUpdate(with: Self)</div><div class=""><br class=""></div><div class="">e.g. names that actually communicate what is going on. </div><div class=""><br class=""></div><div class="">— Taras<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 12 Feb 2016, at 14:23, Matthew Judge 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=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Feb 11, 2016 at 4:27 PM, Rob Mayoff via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr" class=""><div class="gmail_extra"><span class=""><div class="gmail_quote">On Thu, Feb 11, 2016 at 12:54 PM, Jim Hillhouse via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div class="">The present participle of 'union' is technically speaking, 'unioning'. But it is not widely used. In fact, in both Pages and Word, 'unioning' is flagged as a misspelling of 'union'.<div class=""></div></div></blockquote></div><div class="gmail_extra"><br class=""></div></span>Outside of programming, "union" is a noun, not a verb, and "unite" is already a perfectly good verb that means "create the union of". So why not</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra"> func union(with other: Self) -> Self</div><div class="gmail_extra"> func unite(with other: Self)</div><div class="gmail_extra"><br class=""></div></div></blockquote><div class=""> </div><div class="">My biggest problem with this diff is the different treatment of "union" and "intersection"... it is confusing that one is mutating and the other is non-mutating. They are both the same part of speech and both the term of art, so they should both have the same mutability implications.</div><div class=""><br class=""></div><div class="">I'd vote either of the following (leaning toward the first group because I think the term of art implies non-mutating):</div><div class=""><br class=""></div><div class="">func union(other: Self) -> Self</div><div class="">func unite(other: Self)</div><div class="">func intersection(other: Self) -> Self</div><div class="">func intersect(other: Self)</div><div class=""><br class=""></div><div class="">func uniting(other: Self) -> Self</div><div class="">func union(other: Self)</div><div class="">func intersecting(other: Self) -> Self</div><div class="">func intersection(other: Self)</div><div class=""><br class=""></div><div class="">unite and uniting are still reasonably close to union (exactly the same for the first 3 characters which should help with autocomplete discoverability).</div><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr" class=""><div class="gmail_extra"></div></div>
<br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" rel="noreferrer" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></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=""></div></div></body></html>