[swift-evolution] [Proposal] Custom operators

[Антон Жилин]

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 <clattner at apple.com>:

>
> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution <
> swift-evolution at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160408/d9358216/attachment.html>