> On May 24, 2016, at 11:13 AM, Tony Allevato via swift-evolution > <[email protected]> wrote: > > On Mon, May 23, 2016 at 9:20 PM David Sweeris via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > > > On May 18, 2016, at 18:07, plx via swift-evolution > > <[email protected] <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
