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

[Ross O'Brien]

I agree that the colon-separated syntax looks cleaner. However, I agree
with Xiaodi about the stronger/weaker terms being less clear (if only
because I associate those terms with memory management in Swift, not
operator precedence). My personal preference would be for something like
'appliedBefore'/'appliedAfter', so for example:

precedencegroup Multiplication
{
  appliedBefore: Addition
  appliedAfter: Parentheses
}

On Thu, Jun 23, 2016 at 10:24 AM, Xiaodi Wu via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/a6ac5af1/attachment.html>