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