[swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

[Xiaodi Wu]

On Wed, Jun 22, 2016 at 10:24 PM, Joe Groff via swift-evolution <
swift-evolution at swift.org> wrote:

> Proposal link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md
>
> Hello Swift Community,
>
> The review of SE-0077: "Improved operator declarations" ran from May
> 17...23. On June 22, 2016, the core team decided to *return* the first
> version of this proposal for revision. The core design proposed is a clear
> win over the Swift 2 design, but the core team feels that revisions are
> necessary for usability and consistency with the rest of the language:
>
> - The proposed associativity(left) and precedence(<) syntax for
> precedence group attributes doesn’t have a precedent elsewhere in Swift.
> Furthermore, it isn’t clear which relationship < and > correspond to in
> the precedence syntax. The core team feels that it’s more in the character
> of Swift to use colon-separated “key-value” syntax, with associativity,
> strongerThan, and weakerThan keyword labels:
>
>
> precedencegroup Foo {
>
>   associativity: left
>
>   strongerThan: Bar
>
>   weakerThan: Bas
>
> }
>
>
> -If “stronger” and “weaker” relationships are both allowed, that would
> enable different code to express precedence relationships in different,
> potentially confusing ways. To promote consistency and clarity, the core
> team recommends the following restriction: Relationships between precedence
> groups defined within the same module must be expressed exclusively in
> terms of strongerThan. weakerThan can only be used to extend
> the precedence graph relative to another module’s groups, subject to the
> transitivity constraints already described in the proposal. This enforces a
> consistent style internally within modules defining operators.
>
>
This definitely looks cleaner, but the terminology "stronger" and "weaker"
is pretty non-standard. Typically, precedence is said to be above or below
(equivalently, over or under, higher or lower) or, alternatively, before or
after. IMO, before and after are particularly apt terms for operators,
because `*` having precedence before `+` means precisely that `*` is
evaluated before `+`. It's kind of a mixed metaphor to associate precedence
with being stronger and weaker, though I suppose in life as well the
stronger get to go first in line if they want to...


>
> - The proposal states that precedence groups live in a separate namespace
> from other declarations; however, this is unprecedented in Swift, and leads
> to significant implementation challenges. The core team recommends
> that precedence groups exist in the same namespace as all Swift
> declarations. It would be an error to reference a precedence group in value
> contexts.
>
>
> - Placing precedence groups in the standard namespace makes the question
> of naming conventions for precedencegroup declarations important. The core
> team feels that this is an important issue for the proposal to address. As
> a starting point, we recommend CamelCase with a -Precedence suffix, e.g.
> AdditivePrecedence. This is unfortunately redundant in the context of a
> precedencegroup declaration; however, precedencegroups should be rare in
> practice, and it adds clarity at the point of use in operator declarations
> in addition to avoiding naming collisions.
>
>
Conceptually, precedence groups feel to me like enum cases in a squishy
kind of way, only you're not defining them all in one place. I wonder if
that intuition has wide enough appeal that lowerCamelCase might be more
apt. If you stretch that analogy further, it might make sense for
precedence groups to live in their own namespace as though they're cases
for an unutterable enum.

```
// A way of thinking about namespacing precedence groups
// Not actually proposed to be a real thing
enum _PrecedenceGroup : Int {
  case assignment = 90, ternary = 100, disjunctive = 110 /* etc. */
}
```


> The standard library team also requests time to review the proposed names
> of the standard precedence groups
>
>
> - This proposal quietly drops the assignment modifier that exists on
> operators today. This modifier had one important function–an operator
> marked assignment gets folded into an optional chain, allowing foo?.bar
> += 2 to work as foo?(.bar += 2) instead of failing to type-check as (foo?.bar)
> += 2. In practice, all Swift operators currently marked assignment are at
> the equivalent of the Assignment precedence level, so the core team
> recommends making this optional chaining interaction a special feature of
> the Assignment precedence group.
>
>
> - This proposal also accidentally includes declarations of &&= and ||= operators,
> which do not exist in Swift today and should not be added as part of this
> proposal.
>
> Thanks Anton Zhilin for the proposal, and thanks to everyone who
> participated in the review! I will be taking over from Chris as review
> manager for the next round of revision.
>
> -Joe
>
> _______________________________________________
> 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/20160623/1558898e/attachment-0001.html>