[swift-evolution] [Review] SE-0077: Improved operator declarations
Xiaodi Wu
xiaodi.wu at gmail.com
Fri May 20 17:09:18 CDT 2016
On Fri, May 20, 2016 at 5:06 PM, Brandon Knope via swift-evolution <
swift-evolution at swift.org> 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.
>
> Sorry if I missed this suggestion earlier and it was denied :P
>
>
+1 to this, or a version with colons and commas
> 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
>
>
> _______________________________________________
> 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/20160520/644c7341/attachment.html>
More information about the swift-evolution
mailing list