[swift-evolution] [Proposal] Custom operators

[Rainer Brockerhoff]

On 4/8/16 02:59, Chris Lattner via swift-evolution wrote:
>> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution <swift-evolution at swift.org> wrote:
>> Link for newcomers:
>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md <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.
> ... 
> 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 :-)

+10!

> - I definitely agree that a partial ordering between precedences is all that we need/want, and that unspecified relations should be an error.
> ...
> 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 }

Also +10, would be interested in your opinion about:

1) disallowing adding new operator groups outside the stdlib;

2) disallowing adding operators to uncommon groups like subscripting,
function calls, etc.

TIA...
-- 
Rainer Brockerhoff  <rainer at brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://brockerhoff.net/blog/