[swift-evolution] [Proposal] Custom operators

Rainer Brockerhoff rainer at brockerhoff.net
Wed Apr 6 07:34:08 CDT 2016

On 4/4/16 15:21, Daniel Duan via swift-evolution wrote:
>> Антон Жилин via swift-evolution <swift-evolution at ...> writes:
>> 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.
> ...[snip]
> 3.  It may be a good exercise to work out how would each of the builtin
>     operators would be defined with this change and mention it (not the entire
>     definition, but the fact that it's possible, or reasons why it produces
>     any difference) in the proposal.

Quoting the book:
“Swift’s operator precedences and associativity rules are simpler and
more predictable than those found in C and Objective-C. ”
Excerpt From: Apple Inc. “The Swift Programming Language (Swift 2.2
Prerelease).” iBooks.

A word of caution. I've been programming since 1969 (and this does
include languages like PL/I and B6700 ALGOL, for instance). For the past
35 years or so, mostly C and Objective-C. Nevertheless I've been bitten
far too often by misremembering operator precedences — and I refuse to
tack the rules up on my wall, or print them upside down on my t-shirt.

With advancing experience, as complexity increases and available neurons
decrease, I find myself _always_ using parentheses, or even intermediate
variables. It looks unwieldy but it's easier to reason about and to
debug. Why should I have to remember what `a && b || c` means in
practice in a particular language?

With newly-declared operators (especially not newly-declared by ME!) the
potential for confusion becomes ever-higher.

I caution against proposals that allow excess flexibility in defining
operator precedence. Even the existing numerical precedence values can
be abused, and expanding them by using some sort of tree, or (say)
floating-point values, is just a "foolish consistency".

I'd say, have the established precedence groups defined by name, and
allow adding new operators to only some of these groups. Inside those,
group by associativity - perhaps the few right-associative types should
not allow any new operators to be added.

All IMHO of course.
Rainer Brockerhoff  <rainer at brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."

More information about the swift-evolution mailing list