[swift-evolution] [Review] SE-0077: Improved operator declarations

[Matthew Johnson]

Sent from my iPad

> On May 21, 2016, at 7:48 AM, Антон Жилин <antonyzhilin at gmail.com> wrote:
> 
> Updated the proposal:
> https://github.com/Anton3/swift-evolution/blob/master/proposals/0077-operator-precedence.md
> 
> I included many of alternate solutions. Please, reply, if I missed any.
> 
> Still I do not hurry to swap any of alternate solution with syntax used throughout the proposal, although many of them are objectively better.

Looks good.  I really hope we do go with one of the better syntax forms though.

The one thing I don't like is "upper" and "lower".  Those don't make sense to me in this context.  Any of < and >, above and below, greaterThan and lessThan, gt and lt would be better IMO.

> 
> - Anton
> 
> 2016-05-21 1:17 GMT+03:00 Matthew Johnson <matthew at anandabits.com>:
>> 
>>> On May 20, 2016, at 5:06 PM, Brandon Knope <bknope at me.com> wrote:
>>> 
>>> 
>>> 
>>> On May 20, 2016, at 5:56 PM, Антон Жилин via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>>> My working version is still the one in the proposal, but I'm planning to add the alternative versions we discussed, including your and Brent's variants.
>>>> 
>>>> IMHO, original version is heavy, but clear (not to confuse with "clean"). Your lighter version looks more clean, but somewhat less consistent and more free in terms of grammar.
>>>> 
>>>> Also, I've got another version, which is considerably ligher than current one, while being as structured:
>>>> 
>>>> precedence Multiplicative {
>>>>     associativity(left)
>>>>     above(Additive)
>>>>     below(Exponentiative)
>>>> }
>>> 
>>> Why not:
>>> 
>>> precedence Multiplicative {
>>>     associativity left
>>>     above Additive
>>>     below Epxonentiative
>>> }
>>> 
>>> Just seeing if removing the parens reduces some of the noise. 
>> 
>> I would be happy with this.  It is almost the same as what I had suggested, just using > and < rather than above and below (because that was what the proposal was using).  Using words instead is fine with me.  The parens are my biggest objection in this version.  In the original version I also didn’t like the verbosity of `precedencegroup` and the redundant statement `precedence` inside the braces.
>> 
>>> 
>>> Sorry if I missed this suggestion earlier and it was denied :P
>>> 
>>> Brandon 
>>> 
>>> 
>>> 
>>>> 
>>>> - Anton
>>>> 
>>>> 2016-05-21 0:25 GMT+03:00 Matthew Johnson <matthew at anandabits.com>:
>>>>> 
>>>>>> On May 20, 2016, at 4:22 PM, Антон Жилин <antonyzhilin at gmail.com> wrote:
>>>>>> 
>>>>>> Yes, in this case it should be allowed, because this relationship already existed in imported modules. I will add that, too, thanks!
>>>>> 
>>>>> Cool.
>>>>> 
>>>>> What is the latest syntax you are using?  Did you consider any of the lighter weight options?  That subthread died without conclusion (unless I missed something somehow).
>>>>> 
>>>>> 
>>>>>> 
>>>>>> - Anton
>>>>>> 
>>>>>> 2016-05-21 0:01 GMT+03:00 Matthew Johnson <matthew at anandabits.com>:
>>>>>>> 
>>>>>>>>> On May 20, 2016, at 3:51 PM, John McCall <rjmccall at apple.com> wrote:
>>>>>>>>> 
>>>>>>>>> On May 20, 2016, at 1:25 PM, Антон Жилин <antonyzhilin at gmail.com> wrote:
>>>>>>>>> Inline:
>>>>>>>>> 
>>>>>>>>> 2016-05-20 20:58 GMT+03:00 John McCall <rjmccall at apple.com>:
>>>>>>>>>> The transitivity rule plus the ability to define precedence relationships in both directions on a new precedence group allows a new precedence group to create a precedence relationship between existing unrelated precedence groups.  This should be forbidden.
>>>>>>>>> 
>>>>>>>>> Agreed, although there is an alternate solution to allow global-scope relationship definition.
>>>>>>>>> Trying to write it formally:
>>>>>>>>> 
>>>>>>>>> ====begin====
>>>>>>>>> Precedence relationships that, by transitivity rule, create relationship between two imported groups, is an error. Example:
>>>>>>>>> 
>>>>>>>>> // Module X
>>>>>>>>> precedencegroup A { }
>>>>>>>>> precedencegroup C { }
>>>>>>>>> 
>>>>>>>>> // Module Y
>>>>>>>>> import X
>>>>>>>>> precedencegroup B { precedence(> A) precedence(< C) }
>>>>>>>>> 
>>>>>>>>> This results in compilation error "B uses transitivity to define relationship between imported groups A and C".
>>>>>>>>> The rationale behind this is that otherwise one can create relationships between standard precedence groups that are confusing for the reader.
>>>>>>>>> ====end====
>>>>>>>> 
>>>>>>>> Seems good to me.
>>>>>>> 
>>>>>>> Would this be allowed if Module X already defined precedence group C > A (it would not be defining a *new* relationship between A and C in that case)?
>>>>>>> 
>>>>>>>> 
>>>>>>>>>> What's the purpose of equality relationships between precedence groups?
>>>>>>>>> 
>>>>>>>>> Agreed, will remove.
>>>>>>>> 
>>>>>>>> Ok.
>>>>>>>>  
>>>>>>>>>> Your proposal should call out the special treatment of the Assignment and Ternary groups.
>>>>>>>>> 
>>>>>>>>> Do you mean that most operators should define greater precedence than Assignment / Ternary? Or there should be some other special treatment?
>>>>>>>> 
>>>>>>>> Just that they have implicit members.
>>>>>>>> 
>>>>>>>> John.
>>>> 
>>>> _______________________________________________
>>>> 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/20160521/60386f84/attachment.html>