[swift-evolution] [Proposal] Custom operators

Антон Жилин antonyzhilin at gmail.com
Sat Apr 9 07:56:55 CDT 2016


2016-04-09 0:17 GMT+03:00 David Waite <david at alkaline-solutions.com>:

> Based on commit ‘01317e1a’:
> I think that it makes sense for membership to live outside of a precedence
> group. An example is if I wanted to add a new assignment operator ( maybe
> ??= 'assign if nil’), I would want it to have the same precedence as
> existing assignment operators, including precedence with other custom
> operators.

Right, the proposal currently allows defining membership both inside and
outside the precedence group, but I agree that with terse enough syntax,
"outside only" will suffice.

Secondly, I think the relationships between precedence groups should be
> defined outside of an existing precedence group. If I have two libraries
> that declare operators in their own custom groups, I may need to define a
> relationship between those groups.

This is a highly discussable question. "Outside" option makes it easy to
merge standard library operators into a single hierarchy again. Maybe this
question can be formulated as follows: should module creator have total
control over its operators, or can their behaviour be modified by user?

> This leads the group declaration itself being just of a name and
> associativity.
> If group precedence is declared externally, there isn’t a need to support
> ‘>’. Since we are declaring a relationship and not evaluating a
> relationship, there are side-effects that developers will need to
> understand if they are trying to comprehend precedence groups in aggregate.
> Having the groups appear consistently in the same order when defining
> precedence may help with this.

I don't think supporting `>` puts much burden on grammar and consistency,
but yeah, it gets some points for external precedence.

> I still assume these relationships are meant to be constrained to a DAG,
> although there might be cases where cycles (or even having multiple graphs)
> would still be unambiguous. I can’t wrap my head around implementation to
> the point of understanding evaluation if not a DAG yet, nor practical
> reasons to have cycles in relations.
> Two groups may be unable to be declared to be equivalent. First, they need
> to be of the same associativity. Second are also possibilities of graph
> cycles once the relationships of both groups are overlaid. This is actually
> the trouble I alluded to in my first email in the thread.

This time the proposal actually reflects these ideas.

Finally, an infix operator is part of one and only one group. It might make
> sense to have a default group (with no associativity) for operators to fall
> into if they do not declare a precedence group.

I have written about creating a separate unnamed group for each operator.
That is nonsense, of course, that should be a single named group without

Oh wait, Yet another quasi-syntax based on the above:
> precedencegroup Additive, associativity: left
> precedencerelation Additive < Multiplicative
> precedencerelation Range < Additive
> infix operator +, group: Additive

I actually like this syntax (the absence of body, especially), but that
commas are inconsistent with the rest of the language. My take at it (hope
somebody can do better):

precedencegroup Additive : associativity(left)
precedencerelation Additive < Multiplicative
precedencerelation Range < Additive
infix operator + : Additive

> -DW
> On Apr 8, 2016, at 1:28 PM, Антон Жилин via swift-evolution <
> swift-evolution at swift.org> wrote:
> The question 4 (`prefix operator ! { }` or `prefix operator !`) seems
> dead simple, because if we need to declare precedence group in body of
> infix operators, then other operators should have it for consistency.
> It's not.
> I suggest an alternative syntax for that:
> infix operator <> : Comparative
> Colon immediately after the operator may not look the best, but it's the
> only disadvantage I can find. It looks like inheritance and has similar
> meaning.
> So, in this scheme, all operators will have no body.
> I also described two methods to declare that operator belongs to a
> precedence group: in `members` and in operator declaration.
> I suggest that this new syntax looks brief/natural enough to remove
> `members` option entirely. "There should be one - and preferably only one -
> obvious way to do it."
> - Anton
> _______________________________________________
> 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/20160409/1875731b/attachment-0001.html>

More information about the swift-evolution mailing list