[swift-evolution] [Proposal] Custom operators

Sun Apr 3 04:36:00 CDT 2016

Swift 2.2 is out, and I restart discussion on syntax for custom operators.
I insist that this time we should focus less on linguistic aspects.

https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md

Introduction

Replace syntax of operator definition:

infix operator <> { precedence 100 associativity left }

With a directive:

#operator(<>, fixity: infix, associativity: left)

Also replace numeric definition of precedence with separate comparative
precedence definitions:

#precedence(+, lessThan: *)
#precedence(+, equalTo: -)

Swift-evolution thread: link to the discussion thread for that proposal
<https://lists.swift.org/pipermail/swift-evolution>
<https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#motivation>
Motivation
<https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#problems-with-numeric-definition-of-precedence>Problems
with numeric definition of precedence

In the beginning, operators had nice precedence values: 90, 100, 110, 120,
130, 140, 150, 160.

As time went, new and new operators were introduced. Precedence could not
be simply changed, as this would be a breaking change. Ranges got
precedence 135, as got precedence 132. ?? had precedence greater than <,
but less thanas, so it had to be given precedence 131.

Now it is not possible to insert any custom operator between < and ??. It
is an inevitable consequence of current design: it will be impossible to
insert an operator between two existing ones at some point.
<https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#problems-with-a-single-precedence-hierarchy>Problems
with a single precedence hierarchy

Currently, if an operator wants to define precedence by comparison to one
operator, it must do so for all other operators.

In many cases, this is not wished. Example: a & b < c is a common error
pattern. a / b as Double is another one. C++ compilers sometimes emit
warnings on these. Swift does not.

The root of the problem is that precedence is defined between all
operators. If & had precedence defined only by comparison to other bitwise
operators and / – only to arithmetic operators, we would have to place
parentheses in such places, not get subtle bugs, and not ever have to look
at the huge operator precedence table.
<https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#problems-with-current-operator-definition-syntax>Problems
with current operator definition syntax

Some argue that current operator syntax is not consistent with other
language constructs. Properties of operators have dictionary semantics and
should be defined as such. It is a rather weak argument right now, but
after reworking of precedence, the new syntax will be more to place. More
reasons are given below.
<https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#conflicts-of-operator-definitions>Conflicts
of operator definitions

Consider two operator definitions in different modules.

Module A:

infix operator |> { precedence 137 associativity left }

Module B:

infix operator |> { precedence 138 associativity left }

<https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#proposed-solution>Proposed
solution
<https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#change-syntax-for-operator-definition>Change
syntax for operator definition

#operator(<>, fixity: infix, associativity: left)
#operator(!, fixity: postfix)

First parameter of #operator directive is name of the operator. Then goes
required parameter fixity that can be infix,prefix, or postfix. Then, for
infix operators, goes optional associativity parameter that can be left or
right.
<https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#comparative-precedence>Comparative
precedence

Remove precedence property from operator definitions. Instead, introduce
#precedence directive:

#precedence(+, lessThan: *)
#precedence(*, equalTo: /)

Omission of parentheses is allowed only when precedence between the two
operators is defined.

1 + 2 * 3  // ok1 + 2 - 3  // error!
#precedence(-, equalTo: +)1 + 2 - 3  // now ok

Precedence equality can only be defined for operators with same
associativity.
<https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#conflict-resolution>Conflict
resolution

Precedence rules can be added freely across modules. Ability to omit
parentheses around more operators will not break any code in included
modules. On the other hand, conflicting precedence rules result in an error:

#precedence(*, lessThan: +)  // error, previously defined `+` < `*`

Operator definitions do nut cause conflicts, unless they are infix and one
of them has associativity: left, but another one has associativity: right.

#operator(!, fixity: prefix)  // ok, duplicated definitions
#operator(<>, fixity: infix)
#operator(<>, fixity: infix, associativity: left)  // ok, now left associative
#operator(+, fixity: infix, associativity: right)  // error:
associativity conflict

So, if two modules define a custom operator with somewhat similar semantics
(at least associativity), they can be used together. Prefix and postfix
operators can never have conflicts in definitions. If they define different
precedence by comparison to same operators, then, most probably, they had
completely different semantics, and the situation is similar to conflict of
functions.
<https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#detailed-design>Detailed
design

operator keyword and local keywords associativity, precedence, left, right will
be removed.

Directives with following (informal) syntax will be added:

#operator(OPERATOR_NAME, fixity: FIXITY)
#operator(OPERATOR_NAME, fixity: infix, associativity: ASSOCIATIVITY)
#precedence(OPERATOR_NAME, lessThan: OPERATOR_NAME)
#precedence(OPERATOR_NAME, equalTo: OPERATOR_NAME)

<https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#impact-on-existing-code>Impact
on existing code

Standard library operator declarations will need to be rewritten. Some of
the existing precedence rules will need to be rewritten using #precedence
 directive.

More importantly, it needs to be discussed what operator precedence rules
do *not* need to be retained.

User defined operators will need to be rewritten as well. But precedence
will have to be defined by the user. Meanwhile, we can automatically insert
parentheses to user code where needed.
<https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#alternatives-considered>Alternatives
considered
<https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#leave-current-operator-syntax-but-change-precedence>Leave
current operator syntax (but change precedence)

#precedence does not make sense to be defined inside of operator
definition, as it describes relationship of two operators. If so, then we
are left with the following declaration syntax:

prefix operator ! { }infix operator |> { }infix operator <> {
associativity left }

If body of operator can only contain associativity (in some cases), then
the existence of body itself makes no sense.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160403/489b9064/attachment.html>