[swift-evolution] [Proposal] Custom operators

[Maximilian Hünenberger]

Inline

> Am 04.04.2016 um 08:06 schrieb Антон Жилин <antonyzhilin at gmail.com>:
> 
> Thank you for a helpful answer!
> I like the idea of overriding precedence from another module. We won't need to introduce additional keywords or visibility for operators. I will add it to the proposal.
> 
> I assume you mean precedence inside braces of operator, then operator scope makes sense. Self operator could be omit as well, following the idea that we are introducing a new operator and want to compare it to others:
> 
> infix operator * {
>     associativity: left
>     precedenceLess: ^
>     precedenceEqual: /
>     precedenceGreater: +
> }
> infix operator / {
>     associativity: left
>     precedenceLess: ^
>     precedenceEqual: *
>     precedenceGreater: +
> }
> 
> Equivalent precedence rules would be allowed for symmetry in the operator definitions.
> We would still be able to reopen the scope and add precedence and associativity rules.
> I agree that this scheme has advantage of being a smaller change.
> 
> I'm still concerned about syntax.
> Is it OK to have "less, equal, greater" in precedence name?

What do you mean by OK? Other operators like == are weird:

precedence(== == <)
// in comparison to
precedence(== equalTo <)

> Is it OK to have both curly brackets and dictionary syntax (a precedent, I guess)?

That could be a consistency problem. However I'd like to keep a declaration syntax instead of defining operators through compiler directives.

> Is it OK to leave prefix and postfix operators always with empty braces?
> 

I'm fine with that.

> Would it be better to have multiple precedence comparisons at once:
> precedenceGreater: +, -, *, /
> Or one comparison per line will be more readable?
> 
> I will add this to alternatives, but will not swap it with currently stated syntax for now, waiting for some more response.
> 
> What do you think?
> 
> - Anton

After thinking more about it I came to the conclusion that we should have something like "precedence groups" where all operators have the same precedence:

precedenceGroup Additive {
    +, -
}

precedenceGroup Multiplicative {
    *, /
}

// first we could allow an operator to be only
// in one p.Group. Later when we can infer
// precedences we can allow operators to be
// in more than one p.Group (if that is even necessary)


// precedence declaration
precedence(Additive lessThan Multiplicative)

// precedence declarations take
// "precedenceGroup"s and "operator"s.


// It could also work with extensions so you
// can easily insert it in the precedence hierarchy:

infix operator +- {
    associativity: left
}

// more operator declarations ...

extension Additive {
    +-, -+, ++, --
}

// the syntax I used is highly discussable.
// this should mainly be a concept suggestion.
// I think it allows for greater flexibility since you can define
// operator precedences much easier.

With kind regards
- Maximilian
> 
> 2016-04-04 8:06 GMT+03:00 Maximilian Hünenberger <m.huenenberger at me.com>:
>> See inline
>> 
>>> Am 03.04.2016 um 13:26 schrieb Ross O'Brien via swift-evolution <swift-evolution at swift.org>:
>>> 
>>> There is a problem here of duplicated operators or custom precedence, and how that gets passed between modules.
>>> Assume there are three modules, A, B and C. B defines a custom operator **. A and C each define a custom operator ++, and their meanings are different (though, even if their meanings were the same, I'm not sure if they could unify).
>>> 
>>> Module D uses A and B as dependencies and sets a custom precedence on ++ and **. Module E uses B and C and has a different precedence on ++ and **. You're working on Module F which uses D and E. Which ++ and which precedence does F get implicitly?
>>> 
>> 
>> We could allow operator precedence overriding to resolve ambiguity. However this overriding should only be module internal since it would override the existing precedences in the other modules.
>> 
>> @AHTOH
>> Why do you use #keyword ?
>> I think defining a operator with
>> 
>>     infix operator + {
>>          associativity: left
>>     }
>> 
>> is perfectly fine since it is similar to class/struct/enum declaration.
>> 
>>     // and it's precedence
>>     precedence(+ lessThan *)
>> 
>> Note the missing "," and ":" before and after "lessThan" in order to give both operators the same importance (minor issue).
>> 
>> I feel that
>> 
>>     #precedence(+, lessThan: *)
>> 
>> puts too much importance on the first operator.
>> 
>> Best regards
>> - Maximilian
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160404/8df2308c/attachment.html>