Right, `infix` operators without a precedence group logically should be able to be used, just with parentheses everywhere.<div><br></div><div>But users will most likely want to use such operators with `=` without parentheses. It means, such operators should still belong to some precedence groups.</div><div><br></div><div>I suggest that for each such operator, an separate unnamed group should be created. It will have no associativity and precedence greater than Ternary (I actually agree this is the right choice).</div><div><br></div><div>I also think it is OK that other operators will not be able to specify precedence relation with such "unprecedented" operators.</div><div><br></div><div>- Anton</div><div><br>8 Apr 2016, Ross O'Brien wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>If I want to define a new operator, it seems like an unnecessary overhead to have to immediately decide which precedence group it should belong to before it can be used (assuming it doesn't interact with other operators). At the moment, new operators are implicitly assigned a 'default' precedence of 100; can we make it so that new operators are implicitly assigned to a 'default' group with an effective precedence of 100? (I believe this is currently the precedence of Ternary, but I'm not sure if I'd have Ternary be the default group).</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 8, 2016 at 5:59 PM, Антон Жилин <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thank you for your reply, Chris!<div>I was thinking about purging directives from the proposal, and that was what I needed to do it.</div><div>So, the proposal is now completely overhauled:</div><div><a href="https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md" target="_blank">https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md</a></div><div><br></div><div>Yes, Maximilian and I have considered operator/precedence groups and they have now moved from alternatives to main part of the proposal.</div><div><br></div><div>Questions:</div><div>1. Is it OK that associativity is moved to precedence groups and that every operator must belong to a precedence group?</div><div>2. Dictionary-like or "functional keywords"? That is, `associativity: left` or `associativity(left)`? So far, only second form has been used somewhere inside declarations.</div><div>3. First-lower or first-upper? `additive` or `Additive`?</div><div>4. Empty body or no body? `prefix operator ! { }` or `prefix operator !`?</div><div><br></div><div>Just in case, some questions/concerns copied from previous discussion:</div><span><div><br></div><div><div style="font-size:12.8px">1. All precedence groups have a "parent".</div><div style="font-size:12.8px">It means, all operators will want to have precedence higher than Comparative or Ternary, or, at least, Assignment.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">2. Moreover, I could not find any case where I had to write anything other than precedence(>, ...)</div><div style="font-size:12.8px">Of cause, I cheated, because I can control all these declarations.</div><div style="font-size:12.8px">Mere people will have to use `<` to say that Additive, for example, should have less priority than their custom operator.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">But... can you build a custom operator where `<` will actually be needed? I have even stronger doubts on `=`.</div><div style="font-size:12.8px">Maybe we can even contract this feature to `parent(Comparative)` or something without losing any expressivity?</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">3. Can we allow operators to have less priority than `=`?</div><div style="font-size:12.8px">If yes, can you give an example of such operator?</div></div><div style="font-size:12.8px"><br></div></span><div style="font-size:12.8px">- Anton</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-04-08 8:59 GMT+03:00 Chris Lattner <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','clattner@apple.com');" target="_blank">clattner@apple.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution <<a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr">First of all, sorry for the delay. I still hope to finish the discussion and push the proposal to review for Swift 3.0.<div>Link for newcomers:</div><div><a href="https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md" target="_blank">https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md</a></div><div><br></div><div>Sadly, I've moved into the territory opposite to what I had in mind in the beginning: absense of conflict resolution.</div><div>I wanted lightweight directives, but am moving to closed precedence groups.</div><div><br></div><div>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.</div></div></div></blockquote><div><br></div></span><div>Hi Антон,</div><div><br></div><div>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:</div><div><br></div><div>- 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 :-)</div><div>- I definitely agree that a partial ordering between precedences is all that we need/want, and that unspecified relations should be an error.</div><div><br></div><div>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.</div><div><br></div><div>Likewise #precedence is a relationship between two operators. I’d suggest putting them into the body of the operator declaration.</div><div><br></div><div>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:</div><div><br></div><div>infix operator <> {</div><div> associativity: left</div><div> precedenceLessThan: *</div><div> precedenceEqualTo: -</div><div> }</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div><span style="white-space:pre-wrap"> </span>operator group additive {}</div><div><div><span style="white-space:pre-wrap"> </span>operator group multiplicative { greaterThan: additive }</div><div><div><span style="white-space:pre-wrap"> </span>operator group exponential { greaterThan: additive }</div></div><div><br></div><div>Then:</div></div><div><br></div><div><span><div>infix operator + {</div><div> associativity: left</div></span><div> precedence: additive</div><div> }</div><div><div>infix operator - {</div><div> associativity: left</div><div> precedence: additive</div><div> }</div></div><div><br></div><div>etc.</div></div><span><font color="#888888"><div><br></div><div>-Chris</div></font></span></div></div></blockquote></div><br></div></div></div></div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
</blockquote></div>