[swift-evolution] [Proposal] Change infix operator attributes syntax to be more consistent with the rest of the language

[Kevin Lundberg]

> > I don't really like this specific design, though—it doesn't really
> match the look and feel of existing directives.
>
> I propose that all compiler directives (that have arguments) be
> formatted in pseudo-function form:
> #setline(1, file: "main.swift")
> I'll create a proposal for this, which will go hand-to-hand with my
> syntax for operators.
>
> Additionally, I've come up with an idea for complete operators
> overhaul. The main suggestions are as follows:
If you intend to draft a proposal for this that encompasses operators,
I'll happily hold off. My gut feeling though is that a proposal that
standardizes directives and also changes how operators are declared may
be better served if they were split into two distinct proposals.
>
> 1. 
> All operators are available without any pre-definition:
>
> postfix func ! <T>(left: T?) -> T 
>
> func <>(left: Int, right: Int) -> Bool  // assuming infix<>, no
> associativity, no precedence
>
> 1 ||| 2  // error: function |||(Int, Int) is not defined
>
This is interesting, but I wonder if an infix operator function with
more esoteric operator characters would be easily identifiable as an
operator vs a normal function. Operator declarations don't need to be
near their function definitions though, and this is technically possible
to do today anyways, so maybe my concern with this change is unfounded.
One way to make this be 100% clear to the reader though would be to
require infix in front of func, just like prefix and postfix which I
kind of like.
> 2.
> If we want to globally set associativity or precedence for infix
> operators, we write:
>
> #operator(|||, associativity: left, precedence: 100)
>
> These operator configuration directives must not be in conflict. We
> can omit one or both of parameters:
>
> #operator(|||, precedence: 100)
> #operator(|||)  // just disallow other #operator directives
I agree that the compiler directive look is interesting (though it's not
my most preferred method of declaring operators aesthetically). However,
omitting fixity here, as this example does, could constrain the design
of future changes that might add behavior control to prefix and postix
operators, and in my opinion it's a better idea to leave that avenue open.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160307/c7445c9c/attachment-0001.html>