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

Tony Allevato allevato at google.com
Wed May 18 09:21:02 CDT 2016

On Wed, May 18, 2016 at 12:10 AM Brent Royal-Gordon via swift-evolution <
swift-evolution at swift.org> wrote:

> > Or should the compiler only allow those two argument labels for unary
> operator functions? That feels strange since it's not a restriction present
> anywhere else, and it starts to feel like the labels have a dual purpose
> that also falls into the realm of keywords.
> A similar restriction exists on operators currently. Today, Swift does not
> allow keywords on operator parameters:
>  23> prefix func !<T>(prefix value: T) {}
> repl.swift:23:18: error: operator cannot have keyword arguments
> prefix func !<T>(prefix value: T) {}
>                  ^~~~~~~
> 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.

> --
> Brent Royal-Gordon
> Architechies
> _______________________________________________
> 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/20160518/38d469e3/attachment.html>

More information about the swift-evolution mailing list