On 15.06.2016 19:15, Xiaodi Wu wrote:


On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution
<swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

    >  If precedence between two operators is undefined, we cannot omit
    > parentheses.

    Hm.. Probably the initial problem could be solved with this? I.e. if
    we'll have *no* defined precedence between math operators and between
    ?? and between ?: (and probably something else?)  ?


Sorry, I don't see it. The initial question was about chaining of ??
operators. That's a problem with expectations about associativity and not
about precedence, right?

Hmm... The initial question of this thread was about
let result = v1 ?? 0 + v2 ?? 0
Which will resolve to
let result = v1 ?? (0 + v2 ?? 0)

And then the question was raised regarding the ternary operator:
a ? b : c + x + y

So, the question was can we require a parentheses in these cases and if we can, how. I'm not sure if these questions about precedence or associativity.




    As for rules of precedence, I think it is really not important what
    precedence will be assigned for ??/?: as in any case IMO most devs will
    not remember this for sure in situation when one need to write/read
    such complex expression.

    For me, probably I have some extreme opinion: if we have a mix of
    operators from different domains (math and ?? for example) we need
    parentheses to exclude any kind of ambiguity.

    On 15.06.2016 17:53, Антон Жилин wrote:

        Nice points, I also think that unless operators are from the same
        domain,
        more parentheses is better.
        Other than that, what rules do we need? I can name these:
        1. Assignment operators have lower precedence than most operators
        2. Arithmetics has higher precedence than comparative and logical
        operators. I don't think that ?? belongs to arithmetics, it's more like
        control flow.
        3. Unary operators obviously have higher precedence than everything

            I didn't read se-0077 in details, so have no opinion. Probably
            you can

        describe main ideas of it here in two words.
        Replace numeric precedence with precedence relationships between
        pairs of
        operators. If precedence between two operators is undefined, we
        cannot omit
        parentheses.

        My thought was basically: "parentheses between some operators must be
        enforced by the language" <=> "SE-0077 is needed"

        - Anton

        2016-06-15 17:17 GMT+03:00 Vladimir.S <sva...@gmail.com
        <mailto:sva...@gmail.com>
        <mailto:sva...@gmail.com <mailto:sva...@gmail.com>>>:



            On 15.06.2016 16:43, Антон Жилин via swift-evolution wrote:

                `b + c * d / e` is not, obviously.


            obviously, for math operators it seems like we don't need any
            clarifications

                `a ? b : c + x + y` -- I'd also say not, because, well,
        it's ternary
                operator, the special case that everyone should know
        (otherwise it
                looks
                like a mess with ? and : operators).


            Yes, it's ternary operator.  But is it
            a ? b : (c + x + y)
            or
            (a ? b : c) + x + y

            IMO ambiguous.

                `a ?? x + y + z` -- maybe. If not for analogies with || and
        && and
                knowing
                about @autoclosure, I'd say that priority of ?? should be
        very high.


            The same, is it
            a ?? (x + y + z)
            or
            (a ?? x) + y + z

            ? I.e. I'm not asking, just show that the question is not if we
        know
            what does ?? mean, but how all the expression will be treated.

            IMO it's totally false assumption that most of developers(and poor
            beginners) do remember the the correct precedence in such
        expressions
            and in most cases will not make a bug and so we should not
        require the
            parentheses. Imagine how each such expression will be crystal clear
            about the order of processing in *any* Swift source code you
        could find
            anywhere. IMO this will be great advantage of the language.

                Now that I think about it, if job of SE-0077 could be done
        with a
                linter,
                then... do we still need it?


            I didn't read se-0077 in details, so have no opinion. Probably
        you can
            describe main ideas of it here in two words.


                - Anton

                2016-06-15 16:00 GMT+03:00 Vladimir.S <sva...@gmail.com
        <mailto:sva...@gmail.com>
                <mailto:sva...@gmail.com <mailto:sva...@gmail.com>>
                <mailto:sva...@gmail.com <mailto:sva...@gmail.com>
        <mailto:sva...@gmail.com <mailto:sva...@gmail.com>>>>:

                    As I understand, the question is if

                    `a ?? x + y + z`
                    and
                    `a ? b : c + x + y`
                    (or `b + c * d / e`)

                    an "ambiguous case" ?


                    On 15.06.2016 15:42, Антон Жилин via swift-evolution wrote:

                        It's tempting to mention SE-0077 in this context.
        If it's
                accepted,
                        we will
                        be able to make omission of parentheses an error in
                ambiguous cases.

                        - Anton


                        _______________________________________________
                        swift-evolution mailing list
                        swift-evolution@swift.org
        <mailto:swift-evolution@swift.org>
                <mailto:swift-evolution@swift.org
        <mailto:swift-evolution@swift.org>>
                <mailto:swift-evolution@swift.org
        <mailto:swift-evolution@swift.org>
        <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>>

        https://lists.swift.org/mailman/listinfo/swift-evolution




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


    _______________________________________________
    swift-evolution mailing list
    swift-evolution@swift.org <mailto: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

Reply via email to