[swift-evolution] [Review] SE-0077: Improved operator declarations
Антон Жилин
antonyzhilin at gmail.com
Sat May 21 07:48:00 CDT 2016
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.
- 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/e66b2346/attachment.html>
More information about the swift-evolution
mailing list