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

Wed Jan 20 15:29:47 CST 2016

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 at 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 at 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 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
>
>
> _______________________________________________
> 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/6ddbdb40/attachment.html>