On 4/4/16 15:21, Daniel Duan via swift-evolution wrote: >> Антон Жилин via swift-evolution <swift-evolution@...> 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 <[email protected]> Belo Horizonte, Brazil "In the affairs of others even fools are wise In their own business even sages err." http://brockerhoff.net/blog/ _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
