The question 4 (`prefix operator ! { }` or `prefix operator !`) seems dead simple, because if we need to declare precedence group in body of infix operators, then other operators should have it for consistency.
It's not. I suggest an alternative syntax for that: infix operator <> : Comparative Colon immediately after the operator may not look the best, but it's the only disadvantage I can find. It looks like inheritance and has similar meaning. So, in this scheme, all operators will have no body. I also described two methods to declare that operator belongs to a precedence group: in `members` and in operator declaration. I suggest that this new syntax looks brief/natural enough to remove `members` option entirely. "There should be one - and preferably only one - obvious way to do it." - Anton 2016-04-08 19:59 GMT+03:00 Антон Жилин <antonyzhi...@gmail.com>: > Thank you for your reply, Chris! > I was thinking about purging directives from the proposal, and that was > what I needed to do it. > So, the proposal is now completely overhauled: > > https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md > > Yes, Maximilian and I have considered operator/precedence groups and they > have now moved from alternatives to main part of the proposal. > > Questions: > 1. Is it OK that associativity is moved to precedence groups and that > every operator must belong to a precedence group? > 2. Dictionary-like or "functional keywords"? That is, `associativity: > left` or `associativity(left)`? So far, only second form has been used > somewhere inside declarations. > 3. First-lower or first-upper? `additive` or `Additive`? > 4. Empty body or no body? `prefix operator ! { }` or `prefix operator !`? > > Just in case, some questions/concerns copied from previous discussion: > > 1. All precedence groups have a "parent". > It means, all operators will want to have precedence higher than > Comparative or Ternary, or, at least, Assignment. > > 2. Moreover, I could not find any case where I had to write anything other > than precedence(>, ...) > Of cause, I cheated, because I can control all these declarations. > Mere people will have to use `<` to say that Additive, for example, should > have less priority than their custom operator. > > But... can you build a custom operator where `<` will actually be needed? > I have even stronger doubts on `=`. > Maybe we can even contract this feature to `parent(Comparative)` or > something without losing any expressivity? > > 3. Can we allow operators to have less priority than `=`? > If yes, can you give an example of such operator? > > - Anton > > 2016-04-08 8:59 GMT+03:00 Chris Lattner <clatt...@apple.com>: > >> >> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> First of all, sorry for the delay. I still hope to finish the discussion >> and push the proposal to review for Swift 3.0. >> Link for newcomers: >> >> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md >> >> Sadly, I've moved into the territory opposite to what I had in mind in >> the beginning: absense of conflict resolution. >> I wanted lightweight directives, but am moving to closed precedence >> groups. >> >> It's just IMHO, and I think I just need input on this from more people. I >> still have not heard anything from Core team. >> >> >> Hi Антон, >> >> I’m sorry for the delay, I have been out of town recently. I haven’t >> read the upstream thread so I hope this isn’t too duplicative. Here is my >> 2c: >> >> - I completely agree that numeric precedences are lame, it was always the >> “plan” that they’d be removed someday, but that obviously still hasn’t >> happened :-) >> - I definitely agree that a partial ordering between precedences is all >> that we need/want, and that unspecified relations should be an error. >> >> That said, I feel like #operator is a major syntactic regression, both in >> consistency and predictability. We use # for two things: directives (like >> #if) and for expressions (#file). The #operator is a declaration of an >> operator, not an expression or a directive. For declarations, we >> consistently use a keyword, which allows contextual modifiers before them, >> along with a body (which is sometimes optional for certain kinds of >> decls). I feel like you’re trying to syntactically reduce the weight of >> something that doesn’t occur very often, which is no real win in >> expressiveness, and harms consistency. >> >> Likewise #precedence is a relationship between two operators. I’d >> suggest putting them into the body of the operator declaration. >> >> OTOH, the stuff inside the current operator declaration is a random >> series of tokens with no apparent structure. I think it would be >> reasonable to end up with something like: >> >> infix operator <> { >> associativity: left >> precedenceLessThan: * >> precedenceEqualTo: - >> } >> >> Or whatever. The rationale here is that “infix” is primal on the >> operator decl (and thus is outside the braces) but the rest of the stuff >> can be omitted, so it goes inside. >> >> Just in terms of the writing of the proposal, in the "Change precedence >> mechanism” keep in mind that swift code generally doesn’t care about the >> order of declarations (it doesn’t parse top down in the file like C does) >> so the example is a bit misleading. >> >> Question for you: have you considered introducing named precedence >> groups, and having the relationships be between those groups? For example, >> I could see something like: >> >> operator group additive {} >> operator group multiplicative { greaterThan: additive } >> operator group exponential { greaterThan: additive } >> >> Then: >> >> infix operator + { >> associativity: left >> precedence: additive >> } >> infix operator - { >> associativity: left >> precedence: additive >> } >> >> etc. >> >> -Chris >> > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution