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

Wed Jan 20 00:48:56 CST 2016

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 at 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 at 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 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
> >
> >
> > _______________________________________________
> > 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/20160120/42892296/attachment.html>