[swift-evolution] [Proposal] Custom operators

[Антон Жилин]

Thank you for a helpful answer!
I like the idea of overriding precedence from another module. We won't need
to introduce additional keywords or visibility for operators. I will add it
to the proposal.

I assume you mean precedence inside braces of operator, then operator scope
makes sense. Self operator could be omit as well, following the idea that
we are introducing a new operator and want to compare it to others:

infix operator * {
    associativity: left
    precedenceLess: ^
    precedenceEqual: /
    precedenceGreater: +
}
infix operator / {
    associativity: left
    precedenceLess: ^
    precedenceEqual: *
    precedenceGreater: +
}

Equivalent precedence rules would be allowed for symmetry in the operator
definitions.
We would still be able to reopen the scope and add precedence and
associativity rules.
I agree that this scheme has advantage of being a smaller change.

I'm still concerned about syntax.
Is it OK to have "less, equal, greater" in precedence name?
Is it OK to have both curly brackets and dictionary syntax (a precedent, I
guess)?
Is it OK to leave prefix and postfix operators always with empty braces?

Would it be better to have multiple precedence comparisons at once:
precedenceGreater: +, -, *, /
Or one comparison per line will be more readable?

I will add this to alternatives, but will not swap it with currently stated
syntax for now, waiting for some more response.

What do you think?

- Anton

2016-04-04 8:06 GMT+03:00 Maximilian Hünenberger <m.huenenberger at me.com>:

> See inline
>
> Am 03.04.2016 um 13:26 schrieb Ross O'Brien via swift-evolution <
> swift-evolution at swift.org>:
>
> There is a problem here of duplicated operators or custom precedence, and
> how that gets passed between modules.
> Assume there are three modules, A, B and C. B defines a custom operator
> **. A and C each define a custom operator ++, and their meanings are
> different (though, even if their meanings were the same, I'm not sure if
> they could unify).
>
> Module D uses A and B as dependencies and sets a custom precedence on ++
> and **. Module E uses B and C and has a different precedence on ++ and **.
> You're working on Module F which uses D and E. Which ++ and which
> precedence does F get implicitly?
>
>
> We could allow operator precedence overriding to resolve ambiguity.
> However this overriding should only be module internal since it would
> override the existing precedences in the other modules.
>
> @AHTOH
> Why do you use #keyword ?
> I think defining a operator with
>
>     infix operator + {
>          associativity: left
>     }
>
> is perfectly fine since it is similar to class/struct/enum declaration.
>
>     // and it's precedence
>     precedence(+ lessThan *)
>
> Note the missing "," and ":" before and after "lessThan" in order to give
> both operators the same importance (minor issue).
>
> I feel that
>
>     #precedence(+, lessThan: *)
>
> puts too much importance on the first operator.
>
> Best regards
> - Maximilian
>
> _______________________________________________
> 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/20160404/903b5cdd/attachment.html>