[swift-evolution] Proposal: Adding precedence option for prefix and postfix operators

[Jason Nielsen]

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 at 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 at 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 at 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 at 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 at 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 at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160117/e5543569/attachment.html>