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

[plx]

> On May 24, 2016, at 11:13 AM, Tony Allevato via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Mon, May 23, 2016 at 9:20 PM David Sweeris via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> > On May 18, 2016, at 18:07, plx via swift-evolution <swift-evolution at swift.org <mailto: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 agree, but IMHO I would anticipate that each time I needed to use a pre/post-fix method, I’d have to go to the reference and double-check whether:

  T.++(prefix: foo) 

…means  “`foo` is prefixed-to `++`” or “the prefix `++` is prefixed-before `foo`”, and vice-versa for `postfix`; the point of confusion is that *usually* the argument label describe the argument, not the “function position” as it were. 

Not likely to be a huge problem but likely to be confusing on the rare occasions it’s actually necessary to pick the right one.

Something like `prefixedTo:` and `postfixedTo:` would be more self-explanatory but seem clunky; perhaps a better formulation is possible here?

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

It’s definitely an edge case but in some ways it just illustrates the tradeoff being made under this proposal. For this *specific* use case the following are IMHO increasingly self-explanatory:

- `foo.map(T.++)`
- `foo.map(T.++(prefix:))`
- `foo.map(T.incrementThenReturn(_:))`

…with the last approach being clearer in this one scenario, but still having all the other drawbacks that motivated to this proposal. 

I can’t think of a natural scenario where this might come up; maybe something with `!` but even there I can’t think of one.

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

That seems likely and reasonable.

After reflecting on it the main gripe I’d have is I don’t think the `prefix:/postfix:` labels do an ideal job of their roles in this proposal, but there’s probably a better approach to be found within the confines of “normal function” syntax.

> 
>  
> 
> - Dave Sweeris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> 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/20160525/a7530386/attachment.html>