Proposal: change infix operator attributes syntax to be more consistent with the rest of the language


(Kevin Lundberg) #1

Ever since Swift 1.0 I've found the infix operator attribute syntax strange:

infix operator <> { associativity left precedence 100 }

The value of the attribute has no visual cue that ties it to the name of
the attribute. One could arguably read left as its own attribute name
rather than the value set to the associativity attribute, or could read
the wrong pair as one attribute, like "left precedence".

In the spirit of Erica Sadun's recent proposal to make attribute syntax
uniform by using : over =, I'd like to see operator declaration syntax
follow a similar structure:

infix operator <> { associativity: left, precedence: 100 }

In my opinion, this simple change makes operator attributes much more
readable. This also should help future proof readability in operator
attributes if operators gain more of them in the future. A longer list
of attributes with the current syntax would become much harder to read.

The only (minor) sticking point I've noticed is the assignment attribute
in the standard library:
https://github.com/apple/swift/blob/12b793c87f160a0f18bb8762e425174205c5d80a/stdlib/public/core/Policy.swift#L427.
This attribute isn't documented in TSPL and it has no value associated
with it. Since user-defined operators are not meant to be assignment
operators, it may not matter much how these are represented, but
ostensibly some user-defined attribute that has no value may come about
in the future. We could make these attributes simply look like this:

infixoperator+={ associativity:right,precedence: 90,assignment }

or perhaps we could make it so that this attribute must now have a
Boolean value that defaults to false if it isn't provided:

infixoperator+={ associativity:right,precedence: 90,assignment: true }

Any thoughts?

- Kevin


(Paul Ossenbruggen) #2

+1 for the discussion, I was just noticing that myself and was thinking along similar lines.

···

On Mar 5, 2016, at 8:54 PM, Kevin Lundberg via swift-evolution <swift-evolution@swift.org> wrote:

Ever since Swift 1.0 I've found the infix operator attribute syntax strange:

infix operator <> { associativity left precedence 100 }

The value of the attribute has no visual cue that ties it to the name of
the attribute. One could arguably read left as its own attribute name
rather than the value set to the associativity attribute, or could read
the wrong pair as one attribute, like "left precedence".

In the spirit of Erica Sadun's recent proposal to make attribute syntax
uniform by using : over =, I'd like to see operator declaration syntax
follow a similar structure:

infix operator <> { associativity: left, precedence: 100 }

In my opinion, this simple change makes operator attributes much more
readable. This also should help future proof readability in operator
attributes if operators gain more of them in the future. A longer list
of attributes with the current syntax would become much harder to read.

The only (minor) sticking point I've noticed is the assignment attribute
in the standard library:
https://github.com/apple/swift/blob/12b793c87f160a0f18bb8762e425174205c5d80a/stdlib/public/core/Policy.swift#L427.
This attribute isn't documented in TSPL and it has no value associated
with it. Since user-defined operators are not meant to be assignment
operators, it may not matter much how these are represented, but
ostensibly some user-defined attribute that has no value may come about
in the future. We could make these attributes simply look like this:

infixoperator+={ associativity:right,precedence: 90,assignment }

or perhaps we could make it so that this attribute must now have a
Boolean value that defaults to false if it isn't provided:

infixoperator+={ associativity:right,precedence: 90,assignment: true }

Any thoughts?

- Kevin
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Brent Royal-Gordon) #3

infix operator += { associativity: right, precedence: 90, assignment: true }

I'm a little uncomfortable putting what looks for all the world like a parameter list into curly brackets; it just doesn't feel in step with other declarations. (To be fair, I wasn't comfortable with the old way, either.)

Here's what I suggest. Usually, a bunch of parameters modifying a declaration would go in a parenthesized list after the particular keyword they modified, and in this case, `associativity` and `precedence` (and probably `assignment` too, though I don't know for sure since it's not documented) are only valid on an infix operator. That would suggest:

  infix(associativity: right, precedence: 90, assignment) operator +=
  prefix operator -
  postfix operator !

···

--
Brent Royal-Gordon
Architechies


(Dave Abrahams) #4

Ever since Swift 1.0 I've found the infix operator attribute syntax strange:

infix operator <> { associativity left precedence 100 }

The value of the attribute has no visual cue that ties it to the name of
the attribute. One could arguably read left as its own attribute name
rather than the value set to the associativity attribute, or could read
the wrong pair as one attribute, like "left precedence".

In the spirit of Erica Sadun's recent proposal ... using : over =, I'd
like to see operator declaration syntax follow a similar structure:

infix operator <> { associativity: left, precedence: 100 }

<schnipp>

Any thoughts?

LGTM, but you shouldn't use the term “attribute” here; it has a
different meaning in Swift and it's *really* confusing when reading your
proposal.

···

on Sat Mar 05 2016, Kevin Lundberg <swift-evolution@swift.org> wrote:

--
-Dave


(Robert Widmann) #5

I think there's something to this, but I'd prefer it look a bit more like what happened in SE-40 (https://github.com/apple/swift-evolution/blob/714dd43863775705cebc77574287ab0974bfa615/proposals/0040-attributecolons.md) so 'associativity' and 'precedence' are made to look more compiler-construct-y.

infix operator <> {
  @associativity(left)
  @precedence(100)
}

As for assignment operators, if memory serves syntax for them was quickly deprecated because they can be subsumed by making the LHS of an infix operator inout. I'm not sure there needs to be much more at the declaration site than that.

~Robert Widmann

2016/03/05 21:54、Kevin Lundberg via swift-evolution <swift-evolution@swift.org> のメッセージ:

···

Ever since Swift 1.0 I've found the infix operator attribute syntax strange:

infix operator <> { associativity left precedence 100 }

The value of the attribute has no visual cue that ties it to the name of
the attribute. One could arguably read left as its own attribute name
rather than the value set to the associativity attribute, or could read
the wrong pair as one attribute, like "left precedence".

In the spirit of Erica Sadun's recent proposal to make attribute syntax
uniform by using : over =, I'd like to see operator declaration syntax
follow a similar structure:

infix operator <> { associativity: left, precedence: 100 }

In my opinion, this simple change makes operator attributes much more
readable. This also should help future proof readability in operator
attributes if operators gain more of them in the future. A longer list
of attributes with the current syntax would become much harder to read.

The only (minor) sticking point I've noticed is the assignment attribute
in the standard library:
https://github.com/apple/swift/blob/12b793c87f160a0f18bb8762e425174205c5d80a/stdlib/public/core/Policy.swift#L427.
This attribute isn't documented in TSPL and it has no value associated
with it. Since user-defined operators are not meant to be assignment
operators, it may not matter much how these are represented, but
ostensibly some user-defined attribute that has no value may come about
in the future. We could make these attributes simply look like this:

infixoperator+={ associativity:right,precedence: 90,assignment }

or perhaps we could make it so that this attribute must now have a
Boolean value that defaults to false if it isn't provided:

infixoperator+={ associativity:right,precedence: 90,assignment: true }

Any thoughts?

- Kevin
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #6

Personally, I really like this update.

-- Erica

···

On Mar 5, 2016, at 9:54 PM, Kevin Lundberg via swift-evolution <swift-evolution@swift.org> wrote:

Ever since Swift 1.0 I've found the infix operator attribute syntax strange:

infix operator <> { associativity left precedence 100 }

infix operator <> { associativity: left, precedence: 100 }


(Erica Sadun) #7

I like this approach too BUT my only concern is how long it takes to get to the actual name.
I know I probably hate this already (give me time to sleep on it) and I'm not wedded to the
approach, but I'd like to see the operator move left for readability so that it's more like a
func declaration:

operator +=(infix, associativity: right, precedence: 90, assignment)
operator -(prefix)
operator !(postfix)

-- E

···

On Mar 5, 2016, at 10:24 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

infix operator += { associativity: right, precedence: 90, assignment: true }

I'm a little uncomfortable putting what looks for all the world like a parameter list into curly brackets; it just doesn't feel in step with other declarations. (To be fair, I wasn't comfortable with the old way, either.)

Here's what I suggest. Usually, a bunch of parameters modifying a declaration would go in a parenthesized list after the particular keyword they modified, and in this case, `associativity` and `precedence` (and probably `assignment` too, though I don't know for sure since it's not documented) are only valid on an infix operator. That would suggest:

  infix(associativity: right, precedence: 90, assignment) operator +=
  prefix operator -
  postfix operator !

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(TJ Usiyan) #8

I'm not completely sold on the proposed change but, if we were to do
something like this, I suggest we include `fixity` as a parameter and come
up with something for `assignment` (`true` in my example is admittedly
suboptimal ). Those `operator -(prefix) seems strange to me.

operator +=(fixity: infix, associativity: right, precedence: 90,
assignment: true)
operator -(fixity: prefix)
operator !(fixity: postfix)
···

On Sun, Mar 6, 2016 at 12:35 AM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:

I like this approach too BUT my only concern is how long it takes to get
to the actual name.
I know I probably hate this already (give me time to sleep on it) and I'm
not wedded to the
approach, but I'd like to see the operator move left for readability so
that it's more like a
func declaration:

operator +=(infix, associativity: right, precedence: 90, assignment)
operator -(prefix)
operator !(postfix)

-- E

On Mar 5, 2016, at 10:24 PM, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org> wrote:

infix operator += { associativity: right, precedence: 90, assignment: true
}

I'm a little uncomfortable putting what looks for all the world like a
parameter list into curly brackets; it just doesn't feel in step with other
declarations. (To be fair, I wasn't comfortable with the old way, either.)

Here's what I suggest. Usually, a bunch of parameters modifying a
declaration would go in a parenthesized list after the particular keyword
they modified, and in this case, `associativity` and `precedence` (and
probably `assignment` too, though I don't know for sure since it's not
documented) are only valid on an infix operator. That would suggest:

infix(associativity: right, precedence: 90, assignment) operator +=
prefix operator -
postfix operator !

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Kevin Lundberg) #9

I only say attribute because that is what the grammar calls it in TSPL and I wanted to be precise. I agree that it is not an ideal name and that should probably also change in the docs.

···

--
Kevin Lundberg

On Mar 6, 2016, at 12:59 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Sat Mar 05 2016, Kevin Lundberg <swift-evolution@swift.org> wrote:

Ever since Swift 1.0 I've found the infix operator attribute syntax strange:

infix operator <> { associativity left precedence 100 }

The value of the attribute has no visual cue that ties it to the name of
the attribute. One could arguably read left as its own attribute name
rather than the value set to the associativity attribute, or could read
the wrong pair as one attribute, like "left precedence".

In the spirit of Erica Sadun's recent proposal ... using : over =, I'd
like to see operator declaration syntax follow a similar structure:

infix operator <> { associativity: left, precedence: 100 }

<schnipp>

Any thoughts?

LGTM, but you shouldn't use the term “attribute” here; it has a
different meaning in Swift and it's *really* confusing when reading your
proposal.

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Kevin Lundberg) #10

I think there's something to this, but I'd prefer it look a bit more
like what happened in SE-40
(https://github.com/apple/swift-evolution/blob/714dd43863775705cebc77574287ab0974bfa615/proposals/0040-attributecolons.md)
so 'associativity' and 'precedence' are made to look more
compiler-construct-y.

infix operator <> {
  @associativity(left)
  @precedence(100)
}

I'm not opposed to something like this either, however having actual
attributes inside curly braces here looks strange. I don't think
attributes are used in this way anywhere else.

As for assignment operators, if memory serves syntax for them was
quickly deprecated because they can be subsumed by making the LHS of
an infix operator inout. I'm not sure there needs to be much more at
the declaration site than that.

If this is the case, then removing assignment from the declaration of
all the stdlib operators could also be part of this proposal, or broken
out into a separate one if necessary.

···

On 3/6/2016 12:21 AM, Developer wrote:


(Radek Pietruszewski) #11

An improvement, but still seems strange to me to use the curly braces with argument-like syntax here. I don’t think there’s another instance of a syntax like this in Swift.

I’d be leaning more towards something like:

infix operator <> (associativity: left, precedence: 100)

or:

operator <> (infix, associativity: left, precedence: 100)

or even:

#operator <> (infix, associativity: left, precedence: 100)

to save up the “operator” keyword

— Radek

···

On 06 Mar 2016, at 05:54, Kevin Lundberg via swift-evolution <swift-evolution@swift.org> wrote:

Ever since Swift 1.0 I've found the infix operator attribute syntax strange:

infix operator <> { associativity left precedence 100 }

The value of the attribute has no visual cue that ties it to the name of
the attribute. One could arguably read left as its own attribute name
rather than the value set to the associativity attribute, or could read
the wrong pair as one attribute, like "left precedence".

In the spirit of Erica Sadun's recent proposal to make attribute syntax
uniform by using : over =, I'd like to see operator declaration syntax
follow a similar structure:

infix operator <> { associativity: left, precedence: 100 }

In my opinion, this simple change makes operator attributes much more
readable. This also should help future proof readability in operator
attributes if operators gain more of them in the future. A longer list
of attributes with the current syntax would become much harder to read.

The only (minor) sticking point I've noticed is the assignment attribute
in the standard library:
https://github.com/apple/swift/blob/12b793c87f160a0f18bb8762e425174205c5d80a/stdlib/public/core/Policy.swift#L427.
This attribute isn't documented in TSPL and it has no value associated
with it. Since user-defined operators are not meant to be assignment
operators, it may not matter much how these are represented, but
ostensibly some user-defined attribute that has no value may come about
in the future. We could make these attributes simply look like this:

infixoperator+={ associativity:right,precedence: 90,assignment }

or perhaps we could make it so that this attribute must now have a
Boolean value that defaults to false if it isn't provided:

infixoperator+={ associativity:right,precedence: 90,assignment: true }

Any thoughts?

- Kevin
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Joe Groff) #12

IMO, simply repainting the bikeshed here doesn't carry much value, and since operators are purely compile-time syntax sugar, I don't think this is a priority to change for Swift 3.0. I see a couple deeper problems with how we model operators that deserve consideration for a deeper redesign, should you (or anyone else) dare to take them on. Coming up with a good solution to these problems might increase the value add here. For one, modeling relative precedence using a global integer table is bad and opaque, and not every operator makes sense to compose with every other. I think it would make more sense for operators to declare their precedence explicitly relative to the other operators they're intended to compose with. This would make operator declarations more self-documenting, operators more modular, and would also naturally give us the ability to raise errors for nonsensical operator combinations (similar to how C and C++ compilers complain about commonly-misunderstood operator combinations). Second, we don't handle operator conflicts between modules very well at all, giving essentially impossible-to-resolve conflict errors.

-Joe

···

On Mar 5, 2016, at 8:54 PM, Kevin Lundberg via swift-evolution <swift-evolution@swift.org> wrote:

Ever since Swift 1.0 I've found the infix operator attribute syntax strange:

infix operator <> { associativity left precedence 100 }

The value of the attribute has no visual cue that ties it to the name of
the attribute. One could arguably read left as its own attribute name
rather than the value set to the associativity attribute, or could read
the wrong pair as one attribute, like "left precedence".

In the spirit of Erica Sadun's recent proposal to make attribute syntax
uniform by using : over =, I'd like to see operator declaration syntax
follow a similar structure:

infix operator <> { associativity: left, precedence: 100 }

In my opinion, this simple change makes operator attributes much more
readable. This also should help future proof readability in operator
attributes if operators gain more of them in the future. A longer list
of attributes with the current syntax would become much harder to read.

The only (minor) sticking point I've noticed is the assignment attribute
in the standard library:
https://github.com/apple/swift/blob/12b793c87f160a0f18bb8762e425174205c5d80a/stdlib/public/core/Policy.swift#L427.
This attribute isn't documented in TSPL and it has no value associated
with it. Since user-defined operators are not meant to be assignment
operators, it may not matter much how these are represented, but
ostensibly some user-defined attribute that has no value may come about
in the future. We could make these attributes simply look like this:

infixoperator+={ associativity:right,precedence: 90,assignment }

or perhaps we could make it so that this attribute must now have a
Boolean value that defaults to false if it isn't provided:

infixoperator+={ associativity:right,precedence: 90,assignment: true }

Any thoughts?

- Kevin
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Kevin Lundberg) #13

Personally I like the current way of declaring an operator's expected
"fixity" as it reads much more naturally:

infix operator += // reads "an infix operator named +="

when compared to

operator += (infix)
// or
operator += (fixity: infix) // reads as "an operator named += which has
a fixity of infix"

Additionally, (pre|post|in)fix-ness of an operator has a much greater
impact on how the operator is used when compared to
associativity/precedence, and if that was designated as a behavioral
modification parameter like associativity/precedence, then it might lead
one to think that they could just alter the fixity and leave the other
attributes alone even though those attributes are only valid for one of
those fixity types:

operator +=(fixity: prefix, associativity: right, precedence: 90,
assignment: true) // compiler error!

I don't like having the value of one parameter in a list control whether
other parameters are even allowed to be present, since that as far as
I'm aware isn't the case in any other aspect of Swift.

···

On 3/6/2016 12:51 AM, T.J. Usiyan via swift-evolution wrote:

I'm not completely sold on the proposed change but, if we were to do
something like this, I suggest we include `fixity` as a parameter and
come up with something for `assignment` (`true` in my example is
admittedly suboptimal ). Those `operator -(prefix) seems strange to me.

operator +=(fixity: infix, associativity: right, precedence: 90,
assignment: true) 
operator -(fixity: prefix)
operator !(fixity: postfix)

On Sun, Mar 6, 2016 at 12:35 AM, Erica Sadun via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

    I like this approach too BUT my only concern is how long it takes
    to get to the actual name.
    I know I probably hate this already (give me time to sleep on it)
    and I'm not wedded to the
    approach, but I'd like to see the operator move left for
    readability so that it's more like a
    func declaration:

    operator +=(infix, associativity: right, precedence: 90, assignment)
    operator -(prefix)
    operator !(postfix)

    -- E

    On Mar 5, 2016, at 10:24 PM, Brent Royal-Gordon via >> swift-evolution <swift-evolution@swift.org >> <mailto:swift-evolution@swift.org>> wrote:

    infix operator += { associativity: right, precedence: 90,
    assignment: true }

    I'm a little uncomfortable putting what looks for all the world
    like a parameter list into curly brackets; it just doesn't feel
    in step with other declarations. (To be fair, I wasn't
    comfortable with the old way, either.)

    Here's what I suggest. Usually, a bunch of parameters modifying a
    declaration would go in a parenthesized list after the particular
    keyword they modified, and in this case, `associativity` and
    `precedence` (and probably `assignment` too, though I don't know
    for sure since it's not documented) are only valid on an infix
    operator. That would suggest:

    infix(associativity: right, precedence: 90, assignment) operator +=
    prefix operator -
    postfix operator !

    --
    Brent Royal-Gordon
    Architechies

    _______________________________________________
    swift-evolution mailing list
    swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    https://lists.swift.org/mailman/listinfo/swift-evolution

    _______________________________________________
    swift-evolution mailing list
    swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Kevin Lundberg) #14

An improvement, but still seems strange to me to use the curly braces with argument-like syntax here. I don’t think there’s another instance of a syntax like this in Swift.

Absolutely, I feel the same way. Using parentheses does feel more
natural in this case.

I’d be leaning more towards something like:

infix operator <> (associativity: left, precedence: 100)

or:

operator <> (infix, associativity: left, precedence: 100)

or even:

#operator <> (infix, associativity: left, precedence: 100)

to save up the “operator” keyword

I prefer the first option myself (my justification is in another reply
in this thread). Since operator is already a claimed keyword, I wonder
if there's any pressing need to relinquish it.


(Dave Abrahams) #15

I only say attribute because that is what the grammar calls it in TSPL
and I wanted to be precise.

Oh, then I can't fault you for using it, sorry!

I agree that it is not an ideal name and that should probably also
change in the docs.

A guy can dream :wink:

···

on Sun Mar 06 2016, Kevin Lundberg <kevin-AT-klundberg.com> wrote:

--
-Dave


(Kevin Lundberg) #16

All good points, I'll hold off on this for now then. Would addressing the bigger picture issues you bring up be something feasible for Swift 3?

— Kevin

···

On Mar 7, 2016, at 9:08 PM, Joe Groff <jgroff@apple.com> wrote:

IMO, simply repainting the bikeshed here doesn't carry much value, and since operators are purely compile-time syntax sugar, I don't think this is a priority to change for Swift 3.0. I see a couple deeper problems with how we model operators that deserve consideration for a deeper redesign, should you (or anyone else) dare to take them on. Coming up with a good solution to these problems might increase the value add here. For one, modeling relative precedence using a global integer table is bad and opaque, and not every operator makes sense to compose with every other. I think it would make more sense for operators to declare their precedence explicitly relative to the other operators they're intended to compose with. This would make operator declarations more self-documenting, operators more modular, and would also naturally give us the ability to raise errors for nonsensical operator combinations (similar to how C and C++ compilers complain about commonly-misunderstood operator combinations). Second, we don't handle operator conflicts between modules very well at all, giving essentially impossible-to-resolve conflict errors.

-Joe

On Mar 5, 2016, at 8:54 PM, Kevin Lundberg via swift-evolution <swift-evolution@swift.org> wrote:

Ever since Swift 1.0 I've found the infix operator attribute syntax strange:

infix operator <> { associativity left precedence 100 }

The value of the attribute has no visual cue that ties it to the name of
the attribute. One could arguably read left as its own attribute name
rather than the value set to the associativity attribute, or could read
the wrong pair as one attribute, like "left precedence".

In the spirit of Erica Sadun's recent proposal to make attribute syntax
uniform by using : over =, I'd like to see operator declaration syntax
follow a similar structure:

infix operator <> { associativity: left, precedence: 100 }

In my opinion, this simple change makes operator attributes much more
readable. This also should help future proof readability in operator
attributes if operators gain more of them in the future. A longer list
of attributes with the current syntax would become much harder to read.

The only (minor) sticking point I've noticed is the assignment attribute
in the standard library:
https://github.com/apple/swift/blob/12b793c87f160a0f18bb8762e425174205c5d80a/stdlib/public/core/Policy.swift#L427.
This attribute isn't documented in TSPL and it has no value associated
with it. Since user-defined operators are not meant to be assignment
operators, it may not matter much how these are represented, but
ostensibly some user-defined attribute that has no value may come about
in the future. We could make these attributes simply look like this:

infixoperator+={ associativity:right,precedence: 90,assignment }

or perhaps we could make it so that this attribute must now have a
Boolean value that defaults to false if it isn't provided:

infixoperator+={ associativity:right,precedence: 90,assignment: true }

Any thoughts?

- Kevin
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Daniel Duan) #17

Joe Groff via swift-evolution <swift-evolution@...> writes:

For one, modeling relative precedence using a global integer table is bad
and opaque, and not every operator makes sense to compose with every other.

If I'm understanding your first point correctly, the precedence will form a DAG
and we use reachability to determine whether two operators have a valid
relationship. That seems pretty straight forward.

Second, we don't handle operator conflicts between modules very well at
all, giving essentially impossible-to-resolve conflict errors.

Name mangling might help here?

-Joe

>

- Daniel

···

> On Mar 5, 2016, at 8:54 PM, Kevin Lundberg via swift-evolution > > <swift-evolution <at> swift.org> wrote:


(Radek Pietruszewski) #18

I agree “infix operator” reads more naturally, but I find it a bit strange to split operator configuration into fixity prefix and other parameters in curly braces/parentheses.

— Radek

···

On 06 Mar 2016, at 20:46, Kevin Lundberg via swift-evolution <swift-evolution@swift.org> wrote:

Personally I like the current way of declaring an operator's expected "fixity" as it reads much more naturally:

infix operator += // reads "an infix operator named +="

when compared to

operator += (infix)
// or
operator += (fixity: infix) // reads as "an operator named += which has a fixity of infix"


(Kevin Lundberg) #19

If you think of modelling operator behavior representations like an
enum, then fixity naturally feels different compared to the other
behavioral parameters:

enum OpBehavior {
  case prefix
  case postfix
  case infix(associativity: OpAssociativity, precedence: UInt8)
}

enum OpAssociativity { case left, right, none }

The behavioral parameters only apply to infix; making them look like
they could apply to anything by making them syntactic siblings to fixity
may lead one to think they could all be applied everywhere.

What about a modification to what Erica suggested?:

operator += infix(associativity: left, precedence: 90, assignment) //
assuming that assignment needs to stay around for now

···

On 3/6/2016 4:55 PM, Radosław Pietruszewski wrote:

I agree “infix operator” reads more naturally, but I find it a bit
strange to split operator configuration into fixity prefix and other
parameters in curly braces/parentheses.

— Radek

On 06 Mar 2016, at 20:46, Kevin Lundberg via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Personally I like the current way of declaring an operator's expected
"fixity" as it reads much more naturally:

infix operator += // reads "an infix operator named +="

when compared to

operator += (infix)
// or
operator += (fixity: infix) // reads as "an operator named += which
has a fixity of infix"