Proposal: Adding precedence option for prefix and postfix operators

Hi all,

My proposal is to add a precedence option for prefix and postfix
operators. It is great that swift allows for associativity and precedence
for binary operators but it hasn't quite gone all the way to make operator
overloading fully functional (just an opinion). To illustrate consider the
following code:

import CoreFoundation

infix operator ** { associativity right precedence 200 }

func ** (base: Double, power: Double) -> Double {
    return pow(base, power)
}

print(-3**2)
print(0-3**2)

which prints 9 and -9. In the first case because unary minus has higher
precedence as a prefix operator it evaluates to (-3)*(-3) and the second
because - is viewed as a binary operator of lower precedence as (0-(3*3).
Exponentiation has higher precedence than subtraction so -3**2 should be -9
and the two expressions above are mathematically equivalent. I originally
reported this as a bug (SR-552) as to me the point of operator overloading
is to allow you to write numerical expressions cleanly but should give you
the correct mathematical result. The only really useful application I can
think of for operator overloading is basically as a DSL for numerical
expressions. If it doesn't allow you to get correct results without having
to put brackets everywhere it sort of defeats the purpose (just my opinion
of course).

Best regards,
Jason

+1 for me and as far as values go:

prefix -
precedence 150, same as infix * since it is essentially (-1)*

prefix +
same as prefix -

To break the least amount of code:

prefix !
precedence 140, which is higher than any other Bool operator (== is highest with 130)

prefix ~
precedence 170, which is higher than any other binary operator (<< is highest with 160)

···

Am 16.01.2016 um 16:30 schrieb Jason Nielsen via swift-evolution <swift-evolution@swift.org>:

Hi all,

My proposal is to add a precedence option for prefix and postfix operators. It is great that swift allows for associativity and precedence for binary operators but it hasn't quite gone all the way to make operator overloading fully functional (just an opinion). To illustrate consider the following code:

import CoreFoundation

infix operator ** { associativity right precedence 200 }

func ** (base: Double, power: Double) -> Double {
    return pow(base, power)
}

print(-3**2)
print(0-3**2)

which prints 9 and -9. In the first case because unary minus has higher precedence as a prefix operator it evaluates to (-3)*(-3) and the second because - is viewed as a binary operator of lower precedence as (0-(3*3). Exponentiation has higher precedence than subtraction so -3**2 should be -9 and the two expressions above are mathematically equivalent. I originally reported this as a bug (SR-552) as to me the point of operator overloading is to allow you to write numerical expressions cleanly but should give you the correct mathematical result. The only really useful application I can think of for operator overloading is basically as a DSL for numerical expressions. If it doesn't allow you to get correct results without having to put brackets everywhere it sort of defeats the purpose (just my opinion of course).

Best regards,
Jason
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I think they are already the highest precedence. That why they need not to
be set this property.

Also, I think things like

print(-3**2)

print(0-3**2)

should never appear in Swift. As it is hard for human to read.

zhaoxin

···

On Sun, Jan 17, 2016 at 5:21 AM, Maximilian Hünenberger < swift-evolution@swift.org> wrote:

+1 for me and as far as values go:

prefix -
precedence 150, same as infix * since it is essentially (-1)*

prefix +
same as prefix -

To break the least amount of code:

prefix !
precedence 140, which is higher than any other Bool operator (== is
highest with 130)

prefix ~
precedence 170, which is higher than any other binary operator (<< is
highest with 160)

> Am 16.01.2016 um 16:30 schrieb Jason Nielsen via swift-evolution < > swift-evolution@swift.org>:
>
> Hi all,
>
> My proposal is to add a precedence option for prefix and postfix
operators. It is great that swift allows for associativity and precedence
for binary operators but it hasn't quite gone all the way to make operator
overloading fully functional (just an opinion). To illustrate consider the
following code:
>
> import CoreFoundation
>
> infix operator ** { associativity right precedence 200 }
>
> func ** (base: Double, power: Double) -> Double {
> return pow(base, power)
> }
>
> print(-3**2)
> print(0-3**2)
>
> which prints 9 and -9. In the first case because unary minus has higher
precedence as a prefix operator it evaluates to (-3)*(-3) and the second
because - is viewed as a binary operator of lower precedence as (0-(3*3).
Exponentiation has higher precedence than subtraction so -3**2 should be -9
and the two expressions above are mathematically equivalent. I originally
reported this as a bug (SR-552) as to me the point of operator overloading
is to allow you to write numerical expressions cleanly but should give you
the correct mathematical result. The only really useful application I can
think of for operator overloading is basically as a DSL for numerical
expressions. If it doesn't allow you to get correct results without having
to put brackets everywhere it sort of defeats the purpose (just my opinion
of course).
>
> Best regards,
> Jason
> _______________________________________________
> 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

Yes, prefix and postfix operators have highest precedence with postfix
binding first if I recall correctly. That is why I made the proposal so
that it could be modified so that pre- and postfix operators that are
mathematically meaningful can operate as one would expect.

As for statements like -3**2 not being allowed, or hard to read, that is a
personal opinion. It looks perfectly readable to me, just syntactic sugar
for -pow(3,2). I do not think your opinion it is shared by the swift devs
either else why allow operator overloading in the first place?

Best regards,
Jason

···

On Sat, Jan 16, 2016 at 8:36 PM, 肇鑫 <owenzx@gmail.com> wrote:

I think they are already the highest precedence. That why they need not
to be set this property.

Also, I think things like

print(-3**2)

print(0-3**2)

should never appear in Swift. As it is hard for human to read.

zhaoxin

On Sun, Jan 17, 2016 at 5:21 AM, Maximilian Hünenberger < > swift-evolution@swift.org> wrote:

+1 for me and as far as values go:

prefix -
precedence 150, same as infix * since it is essentially (-1)*

prefix +
same as prefix -

To break the least amount of code:

prefix !
precedence 140, which is higher than any other Bool operator (== is
highest with 130)

prefix ~
precedence 170, which is higher than any other binary operator (<< is
highest with 160)

> Am 16.01.2016 um 16:30 schrieb Jason Nielsen via swift-evolution < >> swift-evolution@swift.org>:
>
> Hi all,
>
> My proposal is to add a precedence option for prefix and postfix
operators. It is great that swift allows for associativity and precedence
for binary operators but it hasn't quite gone all the way to make operator
overloading fully functional (just an opinion). To illustrate consider the
following code:
>
> import CoreFoundation
>
> infix operator ** { associativity right precedence 200 }
>
> func ** (base: Double, power: Double) -> Double {
> return pow(base, power)
> }
>
> print(-3**2)
> print(0-3**2)
>
> which prints 9 and -9. In the first case because unary minus has
higher precedence as a prefix operator it evaluates to (-3)*(-3) and the
second because - is viewed as a binary operator of lower precedence as
(0-(3*3). Exponentiation has higher precedence than subtraction so -3**2
should be -9 and the two expressions above are mathematically equivalent.
I originally reported this as a bug (SR-552) as to me the point of operator
overloading is to allow you to write numerical expressions cleanly but
should give you the correct mathematical result. The only really useful
application I can think of for operator overloading is basically as a DSL
for numerical expressions. If it doesn't allow you to get correct results
without having to put brackets everywhere it sort of defeats the purpose
(just my opinion of course).
>
> Best regards,
> Jason
> _______________________________________________
> 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

It's true prefix operators have the highest precedence (like ∞) but it should be lower so `-3**2` gets mathematically correct evaluated to `-9` if such an expression appears.

- Maximilian

···

Am 17.01.2016 um 02:36 schrieb 肇鑫 <owenzx@gmail.com>:

I think they are already the highest precedence. That why they need not to be set this property.

Also, I think things like

print(-3**2)
print(0-3**2)

should never appear in Swift. As it is hard for human to read.

zhaoxin

On Sun, Jan 17, 2016 at 5:21 AM, Maximilian Hünenberger <swift-evolution@swift.org> wrote:
+1 for me and as far as values go:

prefix -
precedence 150, same as infix * since it is essentially (-1)*

prefix +
same as prefix -

To break the least amount of code:

prefix !
precedence 140, which is higher than any other Bool operator (== is highest with 130)

prefix ~
precedence 170, which is higher than any other binary operator (<< is highest with 160)

> Am 16.01.2016 um 16:30 schrieb Jason Nielsen via swift-evolution <swift-evolution@swift.org>:
>
> Hi all,
>
> My proposal is to add a precedence option for prefix and postfix operators. It is great that swift allows for associativity and precedence for binary operators but it hasn't quite gone all the way to make operator overloading fully functional (just an opinion). To illustrate consider the following code:
>
> import CoreFoundation
>
> infix operator ** { associativity right precedence 200 }
>
> func ** (base: Double, power: Double) -> Double {
> return pow(base, power)
> }
>
> print(-3**2)
> print(0-3**2)
>
> which prints 9 and -9. In the first case because unary minus has higher precedence as a prefix operator it evaluates to (-3)*(-3) and the second because - is viewed as a binary operator of lower precedence as (0-(3*3). Exponentiation has higher precedence than subtraction so -3**2 should be -9 and the two expressions above are mathematically equivalent. I originally reported this as a bug (SR-552) as to me the point of operator overloading is to allow you to write numerical expressions cleanly but should give you the correct mathematical result. The only really useful application I can think of for operator overloading is basically as a DSL for numerical expressions. If it doesn't allow you to get correct results without having to put brackets everywhere it sort of defeats the purpose (just my opinion of course).
>
> Best regards,
> Jason
> _______________________________________________
> 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

In that context, I would say 9 is the correct answer. Mathematically speaking, the "-" is part of the number, not an operator.

At least I think that's how it worked last time I was in math class.

- Dave Sweeris

···

On Jan 17, 2016, at 08:24, Maximilian Hünenberger via swift-evolution <swift-evolution@swift.org> wrote:

It's true prefix operators have the highest precedence (like ∞) but it should be lower so `-3**2` gets mathematically correct evaluated to `-9` if such an expression appears.

- Maximilian

Am 17.01.2016 um 02:36 schrieb 肇鑫 <owenzx@gmail.com>:

I think they are already the highest precedence. That why they need not to be set this property.

Also, I think things like

print(-3**2)
print(0-3**2)

should never appear in Swift. As it is hard for human to read.

zhaoxin

On Sun, Jan 17, 2016 at 5:21 AM, Maximilian Hünenberger <swift-evolution@swift.org> wrote:
+1 for me and as far as values go:

prefix -
precedence 150, same as infix * since it is essentially (-1)*

prefix +
same as prefix -

To break the least amount of code:

prefix !
precedence 140, which is higher than any other Bool operator (== is highest with 130)

prefix ~
precedence 170, which is higher than any other binary operator (<< is highest with 160)

> Am 16.01.2016 um 16:30 schrieb Jason Nielsen via swift-evolution <swift-evolution@swift.org>:
>
> Hi all,
>
> My proposal is to add a precedence option for prefix and postfix operators. It is great that swift allows for associativity and precedence for binary operators but it hasn't quite gone all the way to make operator overloading fully functional (just an opinion). To illustrate consider the following code:
>
> import CoreFoundation
>
> infix operator ** { associativity right precedence 200 }
>
> func ** (base: Double, power: Double) -> Double {
> return pow(base, power)
> }
>
> print(-3**2)
> print(0-3**2)
>
> which prints 9 and -9. In the first case because unary minus has higher precedence as a prefix operator it evaluates to (-3)*(-3) and the second because - is viewed as a binary operator of lower precedence as (0-(3*3). Exponentiation has higher precedence than subtraction so -3**2 should be -9 and the two expressions above are mathematically equivalent. I originally reported this as a bug (SR-552) as to me the point of operator overloading is to allow you to write numerical expressions cleanly but should give you the correct mathematical result. The only really useful application I can think of for operator overloading is basically as a DSL for numerical expressions. If it doesn't allow you to get correct results without having to put brackets everywhere it sort of defeats the purpose (just my opinion of course).
>
> Best regards,
> Jason
> _______________________________________________
> 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

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

I'm afraid that is not a correct statement. There is no arguing that -3^2
is -9 and that -3^2 and 0-3^2 are equivalent mathematically.
Exponentiation has higher precedence than - and subtraction is definitely
an operator so -3^2 != (-3)^2. That swift has decided that -3 is
different than 0 -3 (which is an error) is a language design choice which I
think is not a good one (just my opinion of course). I can't think of any
other language that is used for numerics R, matlab, python etc. that makes
spacing like this significant). I realize that you are saying that -3 is a
negative number but what is a negative number by definition? This is all
strange to me.. if you type -3 at the REPL you get -3 if you type +3 you
get an error. So +3 isn't a positive number?

Best regards,
Jason

···

On Sun, Jan 17, 2016 at 11:48 AM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote:

In that context, I would say 9 is the correct answer. Mathematically
speaking, the "-" is part of the number, not an operator.

At least I think that's how it worked last time I was in math class.

- Dave Sweeris

On Jan 17, 2016, at 08:24, Maximilian Hünenberger via swift-evolution < > swift-evolution@swift.org> wrote:

It's true prefix operators have the highest precedence (like ∞) but it
should be lower so `-3**2` gets mathematically correct evaluated to `-9` if
such an expression appears.

- Maximilian

Am 17.01.2016 um 02:36 schrieb 肇鑫 <owenzx@gmail.com>:

I think they are already the highest precedence. That why they need not
to be set this property.

Also, I think things like

print(-3**2)

print(0-3**2)

should never appear in Swift. As it is hard for human to read.

zhaoxin

On Sun, Jan 17, 2016 at 5:21 AM, Maximilian Hünenberger < > swift-evolution@swift.org> wrote:

+1 for me and as far as values go:

prefix -
precedence 150, same as infix * since it is essentially (-1)*

prefix +
same as prefix -

To break the least amount of code:

prefix !
precedence 140, which is higher than any other Bool operator (== is
highest with 130)

prefix ~
precedence 170, which is higher than any other binary operator (<< is
highest with 160)

> Am 16.01.2016 um 16:30 schrieb Jason Nielsen via swift-evolution < >> swift-evolution@swift.org>:
>
> Hi all,
>
> My proposal is to add a precedence option for prefix and postfix
operators. It is great that swift allows for associativity and precedence
for binary operators but it hasn't quite gone all the way to make operator
overloading fully functional (just an opinion). To illustrate consider the
following code:
>
> import CoreFoundation
>
> infix operator ** { associativity right precedence 200 }
>
> func ** (base: Double, power: Double) -> Double {
> return pow(base, power)
> }
>
> print(-3**2)
> print(0-3**2)
>
> which prints 9 and -9. In the first case because unary minus has
higher precedence as a prefix operator it evaluates to (-3)*(-3) and the
second because - is viewed as a binary operator of lower precedence as
(0-(3*3). Exponentiation has higher precedence than subtraction so -3**2
should be -9 and the two expressions above are mathematically equivalent.
I originally reported this as a bug (SR-552) as to me the point of operator
overloading is to allow you to write numerical expressions cleanly but
should give you the correct mathematical result. The only really useful
application I can think of for operator overloading is basically as a DSL
for numerical expressions. If it doesn't allow you to get correct results
without having to put brackets everywhere it sort of defeats the purpose
(just my opinion of course).
>
> Best regards,
> Jason
> _______________________________________________
> 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

_______________________________________________
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

Even though `-3 ** 2` seems to equal 9 but see this result: -3 ^ 2 - Wolfram|Alpha

So this behavior forces you to set correct parenthesis around numbers with a minus sign: (-3) ** 2
In order to make -3 ** 2 visually less ambiguous we could allow (or even require) prefix operators to have a white space separator:
- 3 ** 2

Another example:

3 * -4
Would be in this case also ambiguous for the compiler since `*` and `-` have the same precedence and you are forced to write it as:
3 * (-4)
Which is also mathematically more correct

I just noticed that
3 - -4
Is still unambiguous.
If the precedence of prefix - would be the same as infix `+` and `-` all cases I can think of are ambiguous so you are forced to use correct mathematical syntax:
3 - (-4)

Which could also be an indicator to rewrite it to
3 + 4
And 3 + (-4) to 3 - 4

- Maximilian

···

Am 17.01.2016 um 17:48 schrieb David Sweeris <davesweeris@mac.com>:

In that context, I would say 9 is the correct answer. Mathematically speaking, the "-" is part of the number, not an operator.

At least I think that's how it worked last time I was in math class.

- Dave Sweeris

On Jan 17, 2016, at 08:24, Maximilian Hünenberger via swift-evolution <swift-evolution@swift.org> wrote:

It's true prefix operators have the highest precedence (like ∞) but it should be lower so `-3**2` gets mathematically correct evaluated to `-9` if such an expression appears.

- Maximilian

Am 17.01.2016 um 02:36 schrieb 肇鑫 <owenzx@gmail.com>:

I think they are already the highest precedence. That why they need not to be set this property.

Also, I think things like

print(-3**2)
print(0-3**2)

should never appear in Swift. As it is hard for human to read.

zhaoxin

On Sun, Jan 17, 2016 at 5:21 AM, Maximilian Hünenberger <swift-evolution@swift.org> wrote:
+1 for me and as far as values go:

prefix -
precedence 150, same as infix * since it is essentially (-1)*

prefix +
same as prefix -

To break the least amount of code:

prefix !
precedence 140, which is higher than any other Bool operator (== is highest with 130)

prefix ~
precedence 170, which is higher than any other binary operator (<< is highest with 160)

> Am 16.01.2016 um 16:30 schrieb Jason Nielsen via swift-evolution <swift-evolution@swift.org>:
>
> Hi all,
>
> My proposal is to add a precedence option for prefix and postfix operators. It is great that swift allows for associativity and precedence for binary operators but it hasn't quite gone all the way to make operator overloading fully functional (just an opinion). To illustrate consider the following code:
>
> import CoreFoundation
>
> infix operator ** { associativity right precedence 200 }
>
> func ** (base: Double, power: Double) -> Double {
> return pow(base, power)
> }
>
> print(-3**2)
> print(0-3**2)
>
> which prints 9 and -9. In the first case because unary minus has higher precedence as a prefix operator it evaluates to (-3)*(-3) and the second because - is viewed as a binary operator of lower precedence as (0-(3*3). Exponentiation has higher precedence than subtraction so -3**2 should be -9 and the two expressions above are mathematically equivalent. I originally reported this as a bug (SR-552) as to me the point of operator overloading is to allow you to write numerical expressions cleanly but should give you the correct mathematical result. The only really useful application I can think of for operator overloading is basically as a DSL for numerical expressions. If it doesn't allow you to get correct results without having to put brackets everywhere it sort of defeats the purpose (just my opinion of course).
>
> Best regards,
> Jason
> _______________________________________________
> 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

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

I think I disagree with you.

It is true that in mathematics people generally write (-x)^n to raise -x to the nth power but the notation of exponentiation (i.e. the n is a superscript to the x) makes it look like a postfix operator that binds more tightly than the negation. The general rule in Swift is that pre- and postfix have higher precedence and I don’t think this should be changed just because they do it slightly differently in maths. There’s no equivalent visual cue to superscripting that can make it look like ** binds more tightly than unary minus and I think people who are used to Swift conventions will find it confusing, especially considering that exponentiation is just one of an infinitude of possible binary operators.

Furthermore, many people including myself like to put spaces around our binary operators. So you can argue that

    -3**2

should be -9 (although according to Swift conventions, it obviously is not) but what about

    -3 ** 2

To me, that reads as (-3)**2 pretty unambiguously.

You could argue that I should change my formatting conventions in the case of higher-than-prefix-precedence binary operators but

    -3**-2

and

    someOptional!**2

won’t even compile. You need to put the spaces in so that Swift can identify the operators.

···

On 17 Jan 2016, at 18:19, Jason Nielsen via swift-evolution <swift-evolution@swift.org> wrote:

I'm afraid that is not a correct statement. There is no arguing that -3^2 is -9 and that -3^2 and 0-3^2 are equivalent mathematically. Exponentiation has higher precedence than - and subtraction is definitely an operator so -3^2 != (-3)^2. That swift has decided that -3 is different than 0 -3 (which is an error) is a language design choice which I think is not a good one (just my opinion of course). I can't think of any other language that is used for numerics R, matlab, python etc. that makes spacing like this significant). I realize that you are saying that -3 is a negative number but what is a negative number by definition? This is all strange to me.. if you type -3 at the REPL you get -3 if you type +3 you get an error. So +3 isn't a positive number?

Best regards,
Jason

On Sun, Jan 17, 2016 at 11:48 AM, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:
In that context, I would say 9 is the correct answer. Mathematically speaking, the "-" is part of the number, not an operator.

At least I think that's how it worked last time I was in math class.

- Dave Sweeris

On Jan 17, 2016, at 08:24, Maximilian Hünenberger via swift-evolution <swift-evolution@swift.org> wrote:

It's true prefix operators have the highest precedence (like ∞) but it should be lower so `-3**2` gets mathematically correct evaluated to `-9` if such an expression appears.

- Maximilian

Am 17.01.2016 um 02:36 schrieb 肇鑫 <owenzx@gmail.com>:

I think they are already the highest precedence. That why they need not to be set this property.

Also, I think things like

print(-3**2)
print(0-3**2)

should never appear in Swift. As it is hard for human to read.

zhaoxin

On Sun, Jan 17, 2016 at 5:21 AM, Maximilian Hünenberger <swift-evolution@swift.org> wrote:
+1 for me and as far as values go:

prefix -
precedence 150, same as infix * since it is essentially (-1)*

prefix +
same as prefix -

To break the least amount of code:

prefix !
precedence 140, which is higher than any other Bool operator (== is highest with 130)

prefix ~
precedence 170, which is higher than any other binary operator (<< is highest with 160)

> Am 16.01.2016 um 16:30 schrieb Jason Nielsen via swift-evolution <swift-evolution@swift.org>:
>
> Hi all,
>
> My proposal is to add a precedence option for prefix and postfix operators. It is great that swift allows for associativity and precedence for binary operators but it hasn't quite gone all the way to make operator overloading fully functional (just an opinion). To illustrate consider the following code:
>
> import CoreFoundation
>
> infix operator ** { associativity right precedence 200 }
>
> func ** (base: Double, power: Double) -> Double {
> return pow(base, power)
> }
>
> print(-3**2)
> print(0-3**2)
>
> which prints 9 and -9. In the first case because unary minus has higher precedence as a prefix operator it evaluates to (-3)*(-3) and the second because - is viewed as a binary operator of lower precedence as (0-(3*3). Exponentiation has higher precedence than subtraction so -3**2 should be -9 and the two expressions above are mathematically equivalent. I originally reported this as a bug (SR-552) as to me the point of operator overloading is to allow you to write numerical expressions cleanly but should give you the correct mathematical result. The only really useful application I can think of for operator overloading is basically as a DSL for numerical expressions. If it doesn't allow you to get correct results without having to put brackets everywhere it sort of defeats the purpose (just my opinion of course).
>
> Best regards,
> Jason
> _______________________________________________
> 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

_______________________________________________
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

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

A minus sign can represent both a part of an integer, a binary operator called subtraction and sometimes a prefix operator called negation, as far as mathematics go.

-Sune

···

On 17 Jan 2016, at 18:19, Jason Nielsen via swift-evolution <swift-evolution@swift.org> wrote:
I'm afraid that is not a correct statement. There is no arguing that -3^2 is -9 and that -3^2 and 0-3^2 are equivalent mathematically. Exponentiation has higher precedence than - and subtraction is definitely an operator so -3^2 != (-3)^2.

That is the case because brackets have higher precedence... these are the
rules that you leaned in primary school (BEDMAS -- Brackets,
exponentiation, division, multiplication, addition and subtraction). So
(-x)^n is expressed as (-x)*(-x)*....*(-x) n times (if n is even then
positive, if odd negative). By the same logic -x^n is -(x*x*...*x).
Swift doesn't consider spacing important in terms of precedence else 2+3 *
4 would equal 20 in which case I wouldn't have even made the original bug
report or started this e-mail. There is no concept of spacing in
expressing an equation in math. Again having negation (using computer
science speak unary minus aka the prefix operator - ) having precedence
over any other operator by default is a mistake and limits the utility of
operator overloading in the language.

Best regards,
Jason

···

On Mon, Jan 18, 2016 at 7:51 AM, Jeremy Pereira < jeremy.j.pereira@googlemail.com> wrote:

I think I disagree with you.

It is true that in mathematics people generally write (-x)^n to raise -x
to the nth power but the notation of exponentiation (i.e. the n is a
superscript to the x) makes it look like a postfix operator that binds more
tightly than the negation. The general rule in Swift is that pre- and
postfix have higher precedence and I don’t think this should be changed
just because they do it slightly differently in maths. There’s no
equivalent visual cue to superscripting that can make it look like ** binds
more tightly than unary minus and I think people who are used to Swift
conventions will find it confusing, especially considering that
exponentiation is just one of an infinitude of possible binary operators.

Furthermore, many people including myself like to put spaces around our
binary operators. So you can argue that

    -3**2

should be -9 (although according to Swift conventions, it obviously is
not) but what about

    -3 ** 2

To me, that reads as (-3)**2 pretty unambiguously.

You could argue that I should change my formatting conventions in the case
of higher-than-prefix-precedence binary operators but

    -3**-2

and

    someOptional!**2

won’t even compile. You need to put the spaces in so that Swift can
identify the operators.

> On 17 Jan 2016, at 18:19, Jason Nielsen via swift-evolution < > swift-evolution@swift.org> wrote:
>
> I'm afraid that is not a correct statement. There is no arguing that
-3^2 is -9 and that -3^2 and 0-3^2 are equivalent mathematically.
Exponentiation has higher precedence than - and subtraction is definitely
an operator so -3^2 != (-3)^2. That swift has decided that -3 is
different than 0 -3 (which is an error) is a language design choice which I
think is not a good one (just my opinion of course). I can't think of any
other language that is used for numerics R, matlab, python etc. that makes
spacing like this significant). I realize that you are saying that -3 is a
negative number but what is a negative number by definition? This is all
strange to me.. if you type -3 at the REPL you get -3 if you type +3 you
get an error. So +3 isn't a positive number?
>
> Best regards,
> Jason
>
> On Sun, Jan 17, 2016 at 11:48 AM, David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote:
> In that context, I would say 9 is the correct answer. Mathematically
speaking, the "-" is part of the number, not an operator.
>
> At least I think that's how it worked last time I was in math class.
>
> - Dave Sweeris
>
> On Jan 17, 2016, at 08:24, Maximilian Hünenberger via swift-evolution < > swift-evolution@swift.org> wrote:
>
>> It's true prefix operators have the highest precedence (like ∞) but it
should be lower so `-3**2` gets mathematically correct evaluated to `-9` if
such an expression appears.
>>
>> - Maximilian
>>
>> Am 17.01.2016 um 02:36 schrieb 肇鑫 <owenzx@gmail.com>:
>>
>>> I think they are already the highest precedence. That why they need
not to be set this property.
>>>
>>> Also, I think things like
>>>
>>> print(-3**2)
>>> print(0-3**2)
>>>
>>> should never appear in Swift. As it is hard for human to read.
>>>
>>> zhaoxin
>>>
>>>
>>> On Sun, Jan 17, 2016 at 5:21 AM, Maximilian Hünenberger < > swift-evolution@swift.org> wrote:
>>> +1 for me and as far as values go:
>>>
>>> prefix -
>>> precedence 150, same as infix * since it is essentially (-1)*
>>>
>>> prefix +
>>> same as prefix -
>>>
>>>
>>> To break the least amount of code:
>>>
>>> prefix !
>>> precedence 140, which is higher than any other Bool operator (== is
highest with 130)
>>>
>>> prefix ~
>>> precedence 170, which is higher than any other binary operator (<< is
highest with 160)
>>>
>>> > Am 16.01.2016 um 16:30 schrieb Jason Nielsen via swift-evolution < > swift-evolution@swift.org>:
>>> >
>>> > Hi all,
>>> >
>>> > My proposal is to add a precedence option for prefix and postfix
operators. It is great that swift allows for associativity and precedence
for binary operators but it hasn't quite gone all the way to make operator
overloading fully functional (just an opinion). To illustrate consider the
following code:
>>> >
>>> > import CoreFoundation
>>> >
>>> > infix operator ** { associativity right precedence 200 }
>>> >
>>> > func ** (base: Double, power: Double) -> Double {
>>> > return pow(base, power)
>>> > }
>>> >
>>> > print(-3**2)
>>> > print(0-3**2)
>>> >
>>> > which prints 9 and -9. In the first case because unary minus has
higher precedence as a prefix operator it evaluates to (-3)*(-3) and the
second because - is viewed as a binary operator of lower precedence as
(0-(3*3). Exponentiation has higher precedence than subtraction so -3**2
should be -9 and the two expressions above are mathematically equivalent.
I originally reported this as a bug (SR-552) as to me the point of operator
overloading is to allow you to write numerical expressions cleanly but
should give you the correct mathematical result. The only really useful
application I can think of for operator overloading is basically as a DSL
for numerical expressions. If it doesn't allow you to get correct results
without having to put brackets everywhere it sort of defeats the purpose
(just my opinion of course).
>>> >
>>> > Best regards,
>>> > Jason
>>> > _______________________________________________
>>> > 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
>>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

If you can find a mathematically oriented text that distinguishes between
binary and prefix in regards to "-" I'll buy you a salad.

···

On Mon, Jan 18, 2016 at 11:58 AM, Sune Foldager <cyano@me.com> wrote:

> On 17 Jan 2016, at 18:19, Jason Nielsen via swift-evolution < > swift-evolution@swift.org> wrote:
> I'm afraid that is not a correct statement. There is no arguing that
-3^2 is -9 and that -3^2 and 0-3^2 are equivalent mathematically.
Exponentiation has higher precedence than - and subtraction is definitely
an operator so -3^2 != (-3)^2.

A minus sign can represent both a part of an integer, a binary operator
called subtraction and sometimes a prefix operator called negation, as far
as mathematics go.

-Sune

For the record, I agree with Jeremy (and Dave, and Zhaoxin). I articulated most of the same thoughts on the bug Jason filed when he thought this would be uncontroversial. (This discussion is showing that it is controversial and I'm perfectly glad to be having it.)

Jordan

···

On Jan 18, 2016, at 4:51, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> wrote:

I think I disagree with you.

It is true that in mathematics people generally write (-x)^n to raise -x to the nth power but the notation of exponentiation (i.e. the n is a superscript to the x) makes it look like a postfix operator that binds more tightly than the negation. The general rule in Swift is that pre- and postfix have higher precedence and I don’t think this should be changed just because they do it slightly differently in maths. There’s no equivalent visual cue to superscripting that can make it look like ** binds more tightly than unary minus and I think people who are used to Swift conventions will find it confusing, especially considering that exponentiation is just one of an infinitude of possible binary operators.

Furthermore, many people including myself like to put spaces around our binary operators. So you can argue that

   -3**2

should be -9 (although according to Swift conventions, it obviously is not) but what about

   -3 ** 2

To me, that reads as (-3)**2 pretty unambiguously.

You could argue that I should change my formatting conventions in the case of higher-than-prefix-precedence binary operators but

   -3**-2

and

   someOptional!**2

won’t even compile. You need to put the spaces in so that Swift can identify the operators.

On 17 Jan 2016, at 18:19, Jason Nielsen via swift-evolution <swift-evolution@swift.org> wrote:

I'm afraid that is not a correct statement. There is no arguing that -3^2 is -9 and that -3^2 and 0-3^2 are equivalent mathematically. Exponentiation has higher precedence than - and subtraction is definitely an operator so -3^2 != (-3)^2. That swift has decided that -3 is different than 0 -3 (which is an error) is a language design choice which I think is not a good one (just my opinion of course). I can't think of any other language that is used for numerics R, matlab, python etc. that makes spacing like this significant). I realize that you are saying that -3 is a negative number but what is a negative number by definition? This is all strange to me.. if you type -3 at the REPL you get -3 if you type +3 you get an error. So +3 isn't a positive number?

Best regards,
Jason

On Sun, Jan 17, 2016 at 11:48 AM, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:
In that context, I would say 9 is the correct answer. Mathematically speaking, the "-" is part of the number, not an operator.

At least I think that's how it worked last time I was in math class.

- Dave Sweeris

On Jan 17, 2016, at 08:24, Maximilian Hünenberger via swift-evolution <swift-evolution@swift.org> wrote:

It's true prefix operators have the highest precedence (like ∞) but it should be lower so `-3**2` gets mathematically correct evaluated to `-9` if such an expression appears.

- Maximilian

Am 17.01.2016 um 02:36 schrieb 肇鑫 <owenzx@gmail.com>:

I think they are already the highest precedence. That why they need not to be set this property.

Also, I think things like

print(-3**2)
print(0-3**2)

should never appear in Swift. As it is hard for human to read.

zhaoxin

On Sun, Jan 17, 2016 at 5:21 AM, Maximilian Hünenberger <swift-evolution@swift.org> wrote:
+1 for me and as far as values go:

prefix -
precedence 150, same as infix * since it is essentially (-1)*

prefix +
same as prefix -

To break the least amount of code:

prefix !
precedence 140, which is higher than any other Bool operator (== is highest with 130)

prefix ~
precedence 170, which is higher than any other binary operator (<< is highest with 160)

Am 16.01.2016 um 16:30 schrieb Jason Nielsen via swift-evolution <swift-evolution@swift.org>:

Hi all,

My proposal is to add a precedence option for prefix and postfix operators. It is great that swift allows for associativity and precedence for binary operators but it hasn't quite gone all the way to make operator overloading fully functional (just an opinion). To illustrate consider the following code:

import CoreFoundation

infix operator ** { associativity right precedence 200 }

func ** (base: Double, power: Double) -> Double {
   return pow(base, power)
}

print(-3**2)
print(0-3**2)

which prints 9 and -9. In the first case because unary minus has higher precedence as a prefix operator it evaluates to (-3)*(-3) and the second because - is viewed as a binary operator of lower precedence as (0-(3*3). Exponentiation has higher precedence than subtraction so -3**2 should be -9 and the two expressions above are mathematically equivalent. I originally reported this as a bug (SR-552) as to me the point of operator overloading is to allow you to write numerical expressions cleanly but should give you the correct mathematical result. The only really useful application I can think of for operator overloading is basically as a DSL for numerical expressions. If it doesn't allow you to get correct results without having to put brackets everywhere it sort of defeats the purpose (just my opinion of course).

Best regards,
Jason
_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

TI graphing calculators (at least the ones I've used have different buttons for binary and prefix -, does that count? I'm not sure if they behave differently WRT precedence, though.

What if an operator's precedence could be changed by specific functions? Like +(Int, Int) -> Int is 100 (or whatever the default is), but +(MyType, MyType) has precedence 3?

Does that break anything?

···

On Jan 19, 2016, at 22:54, Jason Nielsen via swift-evolution <swift-evolution@swift.org> wrote:

If you can find a mathematically oriented text that distinguishes between binary and prefix in regards to "-" I'll buy you a salad.

On Mon, Jan 18, 2016 at 11:58 AM, Sune Foldager <cyano@me.com> wrote:
> On 17 Jan 2016, at 18:19, Jason Nielsen via swift-evolution <swift-evolution@swift.org> wrote:
> I'm afraid that is not a correct statement. There is no arguing that -3^2 is -9 and that -3^2 and 0-3^2 are equivalent mathematically. Exponentiation has higher precedence than - and subtraction is definitely an operator so -3^2 != (-3)^2.

A minus sign can represent both a part of an integer, a binary operator called subtraction and sometimes a prefix operator called negation, as far as mathematics go.

-Sune

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

But here you are arguing a case only for exponentiation - which doesn’t exist natively in Swift - and the unary minus operator.

It’s also not true to say spacing is not important in Swift. As I said

    -3**-2

doesn’t even compile. Yes, putting spaces in does not alter precedence, but if you do

    -3 ** -2

it *looks* like the unary minus has higher precedence, and it does today.

What about other unary operators. How do you want the precedence of

   2 ** myExponent!

to go?

Swift today has a fairly simple rule which appears to fall down only in one case, where the unary operator is minus and the binary operator is exponentiation (which is something you’d have to define). I don’t think the additional complexity is worth it.

···

On 20 Jan 2016, at 07:48, Jason Nielsen <drjdnielsen@gmail.com> wrote:

That is the case because brackets have higher precedence... these are the rules that you leaned in primary school (BEDMAS -- Brackets, exponentiation, division, multiplication, addition and subtraction). So (-x)^n is expressed as (-x)*(-x)*....*(-x) n times (if n is even then positive, if odd negative). By the same logic -x^n is -(x*x*...*x). Swift doesn't consider spacing important in terms of precedence else 2+3 * 4 would equal 20 in which case I wouldn't have even made the original bug report or started this e-mail. There is no concept of spacing in expressing an equation in math. Again having negation (using computer science speak unary minus aka the prefix operator - ) having precedence over any other operator by default is a mistake and limits the utility of operator overloading in the language.

To be honest I am pretty surprised how this has evolved. I'm not trying to
ruffle any feathers either so I won't be pushing this any longer. Allowing
for operator overloading to me is simply to allow the programmer to be able
to write concise numerical expressions for objects. Mostly math object
(complex numbers, polynomials, tensors etc.) so that you can write
numerical expressions that look like those you would write down by hand on
paper (I'm sure people can come up with many other uses of operator
overloading but this is the only application that seems very useful to
me). That the swift devs decided to allow for overloading of operators,
and in the case of binary to include associativity and precedence (pretty
unusual in most languages I can think of or know) indicated to me that
drawing in the numerical computing crowd to have a look at swift was
intended (to be honest that is what caught my attention.. also a repl and a
nice looking syntax.. totally subjective of course). That said though if
you are going to allow associativity and precedence in binary operators but
fix the precedence of postfix and prefix you will get the issue I pointed
out. Floating point numbers, unary minus and exponentiation is the example
used but the problem with extend to any other mathematical structure that
you want to overload where a prefix symbol has any meaning. Since swift
sets the precedence of prefix to be highest that means that the concise
numerical expression you are trying to achieve via operator overloading is
going to give you an incorrect mathematical result without sticking in
brackets. To me this seems to defeat the intended purpose but that is just
one man's opinion. Since the lexer and parser can handle precedence and
associativity for binary operators I'd be very surprised if adding
precedence to prefix and postfix would be a serious job. That it might
break code of course is a totally different matter.

Best regards,
Jason

···

On Wed, Jan 20, 2016 at 2:19 PM, Jordan Rose <jordan_rose@apple.com> wrote:

For the record, I agree with Jeremy (and Dave, and Zhaoxin). I articulated
most of the same thoughts on the bug Jason filed when he thought this would
be uncontroversial. (This discussion is showing that it *is* controversial
and I'm perfectly glad to be having it.)

Jordan

On Jan 18, 2016, at 4:51, Jeremy Pereira via swift-evolution < > swift-evolution@swift.org> wrote:

I think I disagree with you.

It is true that in mathematics people generally write (-x)^n to raise -x
to the nth power but the notation of exponentiation (i.e. the n is a
superscript to the x) makes it look like a postfix operator that binds more
tightly than the negation. The general rule in Swift is that pre- and
postfix have higher precedence and I don’t think this should be changed
just because they do it slightly differently in maths. There’s no
equivalent visual cue to superscripting that can make it look like ** binds
more tightly than unary minus and I think people who are used to Swift
conventions will find it confusing, especially considering that
exponentiation is just one of an infinitude of possible binary operators.

Furthermore, many people including myself like to put spaces around our
binary operators. So you can argue that

   -3**2

should be -9 (although according to Swift conventions, it obviously is
not) but what about

   -3 ** 2

To me, that reads as (-3)**2 pretty unambiguously.

You could argue that I should change my formatting conventions in the case
of higher-than-prefix-precedence binary operators but

   -3**-2

and

   someOptional!**2

won’t even compile. You need to put the spaces in so that Swift can
identify the operators.

On 17 Jan 2016, at 18:19, Jason Nielsen via swift-evolution < > swift-evolution@swift.org> wrote:

I'm afraid that is not a correct statement. There is no arguing that -3^2
is -9 and that -3^2 and 0-3^2 are equivalent mathematically.
Exponentiation has higher precedence than - and subtraction is definitely
an operator so -3^2 != (-3)^2. That swift has decided that -3 is
different than 0 -3 (which is an error) is a language design choice which I
think is not a good one (just my opinion of course). I can't think of any
other language that is used for numerics R, matlab, python etc. that makes
spacing like this significant). I realize that you are saying that -3 is a
negative number but what is a negative number by definition? This is all
strange to me.. if you type -3 at the REPL you get -3 if you type +3 you
get an error. So +3 isn't a positive number?

Best regards,
Jason

On Sun, Jan 17, 2016 at 11:48 AM, David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote:
In that context, I would say 9 is the correct answer. Mathematically
speaking, the "-" is part of the number, not an operator.

At least I think that's how it worked last time I was in math class.

- Dave Sweeris

On Jan 17, 2016, at 08:24, Maximilian Hünenberger via swift-evolution < > swift-evolution@swift.org> wrote:

It's true prefix operators have the highest precedence (like ∞) but it
should be lower so `-3**2` gets mathematically correct evaluated to `-9` if
such an expression appears.

- Maximilian

Am 17.01.2016 um 02:36 schrieb 肇鑫 <owenzx@gmail.com>:

I think they are already the highest precedence. That why they need not to
be set this property.

Also, I think things like

print(-3**2)
print(0-3**2)

should never appear in Swift. As it is hard for human to read.

zhaoxin

On Sun, Jan 17, 2016 at 5:21 AM, Maximilian Hünenberger < > swift-evolution@swift.org> wrote:
+1 for me and as far as values go:

prefix -
precedence 150, same as infix * since it is essentially (-1)*

prefix +
same as prefix -

To break the least amount of code:

prefix !
precedence 140, which is higher than any other Bool operator (== is
highest with 130)

prefix ~
precedence 170, which is higher than any other binary operator (<< is
highest with 160)

Am 16.01.2016 um 16:30 schrieb Jason Nielsen via swift-evolution < > swift-evolution@swift.org>:

Hi all,

My proposal is to add a precedence option for prefix and postfix
operators. It is great that swift allows for associativity and precedence
for binary operators but it hasn't quite gone all the way to make operator
overloading fully functional (just an opinion). To illustrate consider the
following code:

import CoreFoundation

infix operator ** { associativity right precedence 200 }

func ** (base: Double, power: Double) -> Double {
   return pow(base, power)
}

print(-3**2)
print(0-3**2)

which prints 9 and -9. In the first case because unary minus has higher
precedence as a prefix operator it evaluates to (-3)*(-3) and the second
because - is viewed as a binary operator of lower precedence as (0-(3*3).
Exponentiation has higher precedence than subtraction so -3**2 should be -9
and the two expressions above are mathematically equivalent. I originally
reported this as a bug (SR-552) as to me the point of operator overloading
is to allow you to write numerical expressions cleanly but should give you
the correct mathematical result. The only really useful application I can
think of for operator overloading is basically as a DSL for numerical
expressions. If it doesn't allow you to get correct results without having
to put brackets everywhere it sort of defeats the purpose (just my opinion
of course).

Best regards,
Jason
_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

FWIW, Swift gives the same result as what you get from bash.

$ echo $[-3**2] $[0-3**2] $[0+-3**2] $[-1*3**2]
9 -9 9 -9

print(-3**2, 0-3**2, 0 + -3**2, -1*3**2)
9.0 -9.0 9.0 -9.0

My math class are quite far back, but I do read -3**2 as "negative three to the power of two"; the - is the negative sign which is part of the number (as Dave said), and not the binary operator for subtraction. By changing the example a little bit, the line is no longer as clear to me:

How does one read -(1+2)**2?
- the sum of one and two to the power of two, multiplied by negative one; so -9 (as Jason likely sees it)
- the sum of one and two multiplied by negative one, to the power of two; so 9 (Swift and bash result)

IMHO, I think that Swift and bash are right (sorry Jason). I’m having also trouble visualizing a need for allowing unary operator to have lower priority than binary ones, mainly because they are marked as prefix/postfix and these words rings like glued/attached to whatever token is before/after; a number, a variable, or a set of parenthesis.

I’m curious as to what a none immediate prefix/postfix unary operator would look like and be useful for, the only thing I came up with is:

let some_result : Bool = !!! a&b|c // A "leading unary operator (up to end of line)
let some_result : Bool = !(a&b|c) // Equivalent in current Swift with "ugly and annoying" parenthesis.

Regards
Dany

···

Le 20 janv. 2016 à 16:29, Jason Nielsen via swift-evolution <swift-evolution@swift.org> a écrit :

To be honest I am pretty surprised how this has evolved. I'm not trying to ruffle any feathers either so I won't be pushing this any longer. Allowing for operator overloading to me is simply to allow the programmer to be able to write concise numerical expressions for objects. Mostly math object (complex numbers, polynomials, tensors etc.) so that you can write numerical expressions that look like those you would write down by hand on paper (I'm sure people can come up with many other uses of operator overloading but this is the only application that seems very useful to me). That the swift devs decided to allow for overloading of operators, and in the case of binary to include associativity and precedence (pretty unusual in most languages I can think of or know) indicated to me that drawing in the numerical computing crowd to have a look at swift was intended (to be honest that is what caught my attention.. also a repl and a nice looking syntax.. totally subjective of course). That said though if you are going to allow associativity and precedence in binary operators but fix the precedence of postfix and prefix you will get the issue I pointed out. Floating point numbers, unary minus and exponentiation is the example used but the problem with extend to any other mathematical structure that you want to overload where a prefix symbol has any meaning. Since swift sets the precedence of prefix to be highest that means that the concise numerical expression you are trying to achieve via operator overloading is going to give you an incorrect mathematical result without sticking in brackets. To me this seems to defeat the intended purpose but that is just one man's opinion. Since the lexer and parser can handle precedence and associativity for binary operators I'd be very surprised if adding precedence to prefix and postfix would be a serious job. That it might break code of course is a totally different matter.

Best regards,
Jason

On Wed, Jan 20, 2016 at 2:19 PM, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:
For the record, I agree with Jeremy (and Dave, and Zhaoxin). I articulated most of the same thoughts on the bug Jason filed when he thought this would be uncontroversial. (This discussion is showing that it is controversial and I'm perfectly glad to be having it.)

Jordan

On Jan 18, 2016, at 4:51, Jeremy Pereira via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I think I disagree with you.

It is true that in mathematics people generally write (-x)^n to raise -x to the nth power but the notation of exponentiation (i.e. the n is a superscript to the x) makes it look like a postfix operator that binds more tightly than the negation. The general rule in Swift is that pre- and postfix have higher precedence and I don’t think this should be changed just because they do it slightly differently in maths. There’s no equivalent visual cue to superscripting that can make it look like ** binds more tightly than unary minus and I think people who are used to Swift conventions will find it confusing, especially considering that exponentiation is just one of an infinitude of possible binary operators.

Furthermore, many people including myself like to put spaces around our binary operators. So you can argue that

   -3**2

should be -9 (although according to Swift conventions, it obviously is not) but what about

   -3 ** 2

To me, that reads as (-3)**2 pretty unambiguously.

You could argue that I should change my formatting conventions in the case of higher-than-prefix-precedence binary operators but

   -3**-2

and

   someOptional!**2

won’t even compile. You need to put the spaces in so that Swift can identify the operators.

On 17 Jan 2016, at 18:19, Jason Nielsen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I'm afraid that is not a correct statement. There is no arguing that -3^2 is -9 and that -3^2 and 0-3^2 are equivalent mathematically. Exponentiation has higher precedence than - and subtraction is definitely an operator so -3^2 != (-3)^2. That swift has decided that -3 is different than 0 -3 (which is an error) is a language design choice which I think is not a good one (just my opinion of course). I can't think of any other language that is used for numerics R, matlab, python etc. that makes spacing like this significant). I realize that you are saying that -3 is a negative number but what is a negative number by definition? This is all strange to me.. if you type -3 at the REPL you get -3 if you type +3 you get an error. So +3 isn't a positive number?

Best regards,
Jason

On Sun, Jan 17, 2016 at 11:48 AM, David Sweeris via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
In that context, I would say 9 is the correct answer. Mathematically speaking, the "-" is part of the number, not an operator.

At least I think that's how it worked last time I was in math class.

- Dave Sweeris

On Jan 17, 2016, at 08:24, Maximilian Hünenberger via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

It's true prefix operators have the highest precedence (like ∞) but it should be lower so `-3**2` gets mathematically correct evaluated to `-9` if such an expression appears.

- Maximilian

…snip...

On Sun, Jan 17, 2016 at 5:21 AM, Maximilian Hünenberger <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1 for me and as far as values go:

prefix -
precedence 150, same as infix * since it is essentially (-1)*

prefix +
same as prefix -

To break the least amount of code:

prefix !
precedence 140, which is higher than any other Bool operator (== is highest with 130)

prefix ~
precedence 170, which is higher than any other binary operator (<< is highest with 160)

Am 16.01.2016 um 16:30 schrieb Jason Nielsen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

Hi all,

My proposal is to add a precedence option for prefix and postfix operators. It is great that swift allows for associativity and precedence for binary operators but it hasn't quite gone all the way to make operator overloading fully functional (just an opinion). To illustrate consider the following code:

import CoreFoundation

infix operator ** { associativity right precedence 200 }

func ** (base: Double, power: Double) -> Double {
   return pow(base, power)
}

print(-3**2)
print(0-3**2)

which prints 9 and -9. In the first case because unary minus has higher precedence as a prefix operator it evaluates to (-3)*(-3) and the second because - is viewed as a binary operator of lower precedence as (0-(3*3). Exponentiation has higher precedence than subtraction so -3**2 should be -9 and the two expressions above are mathematically equivalent. I originally reported this as a bug (SR-552) as to me the point of operator overloading is to allow you to write numerical expressions cleanly but should give you the correct mathematical result. The only really useful application I can think of for operator overloading is basically as a DSL for numerical expressions. If it doesn't allow you to get correct results without having to put brackets everywhere it sort of defeats the purpose (just my opinion of course).

Best regards,
Jason