[swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `Any<P1, P2>`

[Tony Allevato]

On Wed, Jun 22, 2016 at 12:34 PM Scott James Remnant via swift-evolution <
swift-evolution at swift.org> wrote:

> Have given this a thorough review, both the final proposal, and its
> development during the draft phases on the list, etc.
>
> Unfortunately I have to give the final proposal as it stands a strong -1.
>
> 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.
>
>
> In Swift, the & operator is not used for composition, it serves only as
> the “Bitwise AND" operator for integer operations.
>
>
> OptionSetType gives a good example, where Swift has actively abandoned &
> for composition. Previously code was in an Obj-C style, e.g.
>
>   NSOptionBox & NSOptionCarton
>
> but now uses “,” for composition within an array context:
>
>   [.box, .carton]
>

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.

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.

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".



>
> For this reason, I find that the pattern `<…, …, …>` is still a more
> Swift-y type composition syntax than the proposal.
>
> Scott
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160622/76cbddc2/attachment.html>