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 <[email protected]>: > > On May 20, 2016, at 5:06 PM, Brandon Knope <[email protected]> wrote: > > > > On May 20, 2016, at 5:56 PM, Антон Жилин via swift-evolution < > [email protected]> 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 <[email protected]>: > >> >> On May 20, 2016, at 4:22 PM, Антон Жилин <[email protected]> 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 <[email protected]>: >> >>> >>> On May 20, 2016, at 3:51 PM, John McCall <[email protected]> wrote: >>> >>> On May 20, 2016, at 1:25 PM, Антон Жилин <[email protected]> wrote: >>> Inline: >>> >>> 2016-05-20 20:58 GMT+03:00 John McCall <[email protected]>: >>> >>>> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
