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

[Tony Allevato]

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
parse
- 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>