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

Tony Allevato allevato at google.com
Tue May 24 11:13:02 CDT 2016

On Mon, May 23, 2016 at 9:20 PM David Sweeris via swift-evolution <
swift-evolution at swift.org> wrote:

> > On May 18, 2016, at 18:07, plx via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > How hard would it be to e.g. simply allow something like this:
> >
> >  func ==<T:Equatable>(lhs: T, rhs: T) -> Bool {
> >    return lhs T.== rhs
> >  }
> >
> > …instead of the `T.==(lhs,rhs)` syntax?
> Yeah, I've been meaning to suggest that. And 'T.++(x)' and '(x)T.++' for
> prefix and postfix, respectfully.

The "fully-qualified operator" syntax was one that was discussed in some of
the original e-mail threads. It was part an earlier draft of the proposal,
but I changed it to the function call syntax because

- visually, it's a bit tricky to parse with the eyes
- I wasn't sure whether it would pose similar problems for the compiler to
- It doesn't solve the (admittedly edge case) issue of not being able to
refer distinctly to prefix/postfix operators that have the same name as a
first-class function without wrapping the invocation in a closure
- Chris Lattner recommended changing it to the function call syntax after a
core team discussion before the proposal PR was accepted, so it's possible
they have more insight into the parsing/implementation issues?

> - Dave Sweeris
> _______________________________________________
> 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/20160524/00aa9498/attachment.html>

More information about the swift-evolution mailing list