[swift-evolution] [swift-evolution-announce] [Review] SE-0091: Improving operator requirements in protocols

[Kevin Lundberg]

On 5/18/2016 10:21 AM, Tony Allevato wrote:
> On Wed, May 18, 2016 at 12:10 AM Brent Royal-Gordon via
> swift-evolution <swift-evolution at swift.org
> <mailto:swift-evolution at swift.org>> wrote:
>
>     ...
>
>     What I'm suggesting is that, on unary operators, Swift require
>     either the keyword "prefix" or "postfix" on the argument, and use
>     that to differentiate between prefix and postfix operators. No
>     other keyword would be used or permitted, and no keyword would be
>     used or permitted on infix operators' arguments.
>
>
> I would be supportive of this. The syntax for static prefix/postfix
> operators in that proposal was a matter of some earlier debate (in
> e-mail threads, and a couple comments in the pull request
> <https://github.com/apple/swift-evolution/pull/283>) and was one of
> the parts of the proposal I thought felt less natural.
>
> I think we should definitely have a solution that avoids duplication
> (so not having a `prefix` as a leading keyword and as an argument
> label). Since prefix/postfix operators are required to only have one
> argument, and those arguments must already not have labels,
> introducing prefix/postfix as labels instead of keywords to
> distinguish them seems natural.
>
> The other major benefit (which I mention in a PR comment above) is
> that, if you have a prefix and postfix operator with the same name,
> there is no way currently to get function references to both of them
> (for passing to other algorithms), because there are no labels used to
> distinguish them. For example, if you use `++` as a function reference
> (ignoring the fact that it's deprecated), the REPL takes the last one
> that was defined. (I didn't test what the compiler does, but
> presumably it's arbitrary depending on the ordering of the data
> structures used to store those operators.) Using argument labels would
> solve this problem as well.

These are good arguments. After thinking on it more and reading these
then I do support this change over my proposed change, especially given
that there is already precedent to control the form of operator function
definitions in this way that I was unaware of.

As far as binary operators go, would they need to have a mandatory _ in
front of each argument to satisfy what you propose, Brent? That is:

static func ==(_ lhs: Self, _ rhs: Self) -> Bool

...since by default lhs and rhs would be externally visible argument
labels, or is it better to not impose any such restriction and keep
things the way they are? The compiler could also mandate that those
names be lhs and rhs to keep consistency with prefix and postfix, but
that seems like it might not be palatable, and would probably need to be
bikeshedded a bunch at the very least.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160518/6e5c3d78/attachment.html>