<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Jun 22, 2016 at 12:34 PM Scott James Remnant via swift-evolution <<a href="mailto:swift-evolution@swift.org">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">Have given this a thorough review, both the final proposal, and its development during the draft phases on the list, etc.<br>
<br>
Unfortunately I have to give the final proposal as it stands a strong -1.<br>
<br>
While I appreciate the future benefits of more generic existential types, the final proposal introduces syntax that is flat-out confusing and inconsistent with the rest of Swift 3.<br>
<br>
<br>
In Swift, the & operator is not used for composition, it serves only as the “Bitwise AND" operator for integer operations.<br>
<br>
<br>
OptionSetType gives a good example, where Swift has actively abandoned & for composition. Previously code was in an Obj-C style, e.g.<br>
<br>
NSOptionBox & NSOptionCarton<br>
<br>
but now uses “,” for composition within an array context:<br>
<br>
[.box, .carton]<br></blockquote><div><br></div><div><span style="line-height:1.5">The equivalent to [.box, .carton] in Swift 1 option sets would have been "NSOptionBox | NSOptionCarton", not "&". In that sense, we can't compare '&' in that context to '&' in this one.</span></div><div><br></div><div>We shouldn't necessarily let analogies to bitwise operations affect us here because the operations are so dissimilar and clear from context—they only happen to share the same symbol. The same could be said for addition vs. string concatenation (and actually has been recently on this list). String concatenation is formally a multiplicative operation, not an additive one, and operates on completely different types than numeric ones, but we use + for historical reasons and because it's clear to the user.</div><div><br></div><div>Likewise, the symbol "&" here is quite clear to the user, and I would argue more so than the protocol<> or Any<> syntaxes (the former because eventually this may be extended to non-protocol types, and the latter because it's ambiguous about whether it's "any type conforming to" or "a type conforming to any of".</div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5"> </span><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For this reason, I find that the pattern `<…, …, …>` is still a more Swift-y type composition syntax than the proposal.<br>
<br>
Scott<br>
<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>
</blockquote></div></div>