> Am 05.04.2016 um 17:29 schrieb Антон Жилин <[email protected]>:
>
> David Waite stated a major drawback of precedence groups.
>
> People will often create tiny precedence groups for their modules, and user
> will find that some of them should actually be the same. They will add
> precedenceEqualTo, but all these equivalent groups will still exist. This
> problem cannot occur with transitive precedence propagation. So precedence
> groups really create more problems than solve.
>
> - Anton
Do you mean these drawbacks?
"
> However, this may create more issues than it solves (two frameworks creating
> their own custom operators, putting them in custom precedence groups, and the
> consumer decides the two precedence groups are really equivalent)
>
> -DW
"
What is the problem? Changing the relative precedence of external operators in
your file? Doesn't the same "problem" occur in your proposal (only with one
operator)?
What is the difference between overriding an operator function like this:
func + (l: Int, r: Int) -> Int {
return 0
}
This can also mess up your code...
I'm sorry if I haven't understood your point.
From the other email:
> I meant, are names `precedenceLessThan`, `precedenceEqualTo` a bit clunky?
> Maybe:
>
> associativity(left)
> precedence(lessThan: +)
> precedence(equalTo: +)
>
> It also solves my concern about dictionary inside braces.
I prefer "precedence(+ lessThan *)". However I don't think it's Swift style
since "lessThan" is like an infix operator with letters although the symmetry
between "+" and "*" would be nicely handled by such operator.
> Precedence groups have a great benefit of additional symmetry. Transitive
> precedence propagation, on the other hand, also has benefits:
>
> 1. It does not introduce new entities, just some rules for compiler
> 2. It does not add new keywords. In your current wording, we have to take
> precedence and precedenceGroup as keywords, that's why I originally preferred
> directives
Both 1 and 2 are true but I still prefer to use declarations since they provide
exactly one location where to put operators with equal precedence.
By the way "precedence" is already a keyword... One more to go :)
> 3. We actually think in terms of operators, not groups.
> If I want to say that my operator should have the same priority as `+`, I'd
> rather say that I want it to have priority of plus and minus, not "belong to
> multiplicative group".
> If I declare <$> and want it to have same priority as <*>, it would be more
> difficult to invent some name for their group like FunctorManipulator.
>
I think this deserves more discussion:
Should we allow "precedence(... equalTo ...)" for operators if we have
precedence groups?
Such a precedence declaration would be contrary to my argument above: declare
equal operator precedences in one place, which is more maintainable.
> On the other hand, in your solution you have a list of global rules and don't
> really need braces. How about this?
>
> #precedenceGroup(Additive)
> #precedenceGroup(Multiplicative)
> #precedence(Additive, less, Multiplicative)
> #operator(+, infix, associativity: left, group: Additive)
> #operator(*, infix, associativity: left, group: Multiplicative)
> #operator(<>, infix)
>
> So precedence group is just a tag that can be used in precedence rules and
> assigned to operators at declaration.
Although it is consistent with your proposal for me it is too much repetition
and "code noise". Compare:
infix operator + { associativity: left }
infix operator * { associativity: left }
infix operator <> {}
precedenceGroup Additive { + }
precedenceGroup Multiplicative { * }
precedence(Additive lessThan Multiplicative)
Which is in my opinion way more readable even without syntax highlighting.
Thank You for sharing Your thoughts which have enriched me! :)
Best regards
- Maximilian
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
