<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 24, 2016, at 11:13 AM, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, May 23, 2016 at 9:20 PM David Sweeris via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
> On May 18, 2016, at 18:07, plx via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
> How hard would it be to e.g. simply allow something like this:<br class="">
><br class="">
> func ==<T:Equatable>(lhs: T, rhs: T) -> Bool {<br class="">
> return lhs T.== rhs<br class="">
> }<br class="">
><br class="">
> …instead of the `T.==(lhs,rhs)` syntax?<br class="">
<br class="">
Yeah, I've been meaning to suggest that. And 'T.++(x)' and '(x)T.++' for prefix and postfix, respectfully.<br class=""></blockquote><div class=""><br class=""></div><div class="">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</div><div class=""><br class=""></div><div class="">- visually, it's a bit tricky to parse with the eyes</div></div></div></div></blockquote><div><br class=""></div><div>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:</div><div><br class=""></div><div> T.++(prefix: foo) </div><div><br class=""></div><div>…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. </div><div><br class=""></div><div>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.</div><div><br class=""></div><div>Something like `prefixedTo:` and `postfixedTo:` would be more self-explanatory but seem clunky; perhaps a better formulation is possible here?</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">- I wasn't sure whether it would pose similar problems for the compiler to parse</div><div class="">- 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</div></div></div></div></blockquote><div><br class=""></div><div>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:</div><div><br class=""></div><div>- `foo.map(T.++)`</div><div>- `foo.map(T.++(prefix:))`</div><div>- `foo.map(T.incrementThenReturn(_:))`</div><div><br class=""></div><div>…with the last approach being clearer in this one scenario, but still having all the other drawbacks that motivated to this proposal. </div><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">- 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?</div></div></div></div></blockquote><div><br class=""></div><div>That seems likely and reasonable.</div><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="">
- Dave Sweeris<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>