[swift-evolution] [Review] SE-0077: Improved operator declarations

[T.J. Usiyan]

        * What is your evaluation of the proposal?
+1
        * Is the problem being addressed significant enough to warrant a
change to Swift?
Yes. Definitely. Operator overloading is currently fine in only the
simplest of cases.
        * Does this proposal fit well with the feel and direction of Swift?
I think so, yes.
        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
No
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

I followed the original thread and have been wrangling precedence for a
while now.



One problem that I have encountered with operators that I think still needs
solving is operators from different libraries colliding with regard to
precedence.

`^` is the example that bit me most recently. Swift has one with left
fixity at 160. I wanted to overload it with right fixity for math
operators. The only way that I have thought involves
- precedence groups are tied to a module
- overloads in modules are tied to specific precedence groups.

I have *not a clue* about how feasible this solution is, but it would allow
greater flexibility and, at least in my opinion, more understandable
behavior. Attempting to overload `^` right now, especially with right
fixity, results in confusing behavior.




On Tue, May 17, 2016 at 11:30 PM, Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0077: Improved operator declarations" begins now and
> runs through May 23. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
>         https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
>
>         * What is your evaluation of the proposal?
>         * Is the problem being addressed significant enough to warrant a
> change to Swift?
>         * Does this proposal fit well with the feel and direction of Swift?
>         * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>         * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
>         https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
>
>
> _______________________________________________
> 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/20160517/482030f8/attachment.html>