On Wed, Jun 15, 2016 at 11:36 AM Xiaodi Wu <xiaodi...@gmail.com> wrote:
> On Wed, Jun 15, 2016 at 1:31 PM, Saagar Jha <saagarjh...@gmail.com> wrote: > >> Yes. They’re all operators we know about already, and the same argument >> applies. Just like you wouldn’t change + to have a higher precedence than >> *, bitwise operators already have their own, uniform precedences. I can’t >> see any reason not to have one, other than confusion from those who aren’t >> completely sure how they function-in which case they’re better of taking a >> look at the docs (or Quick Help, as another thread suggests) to learn how >> they work. >> > > FYI, the relative precedence of arithmetic and bitwise operators is not > the same across languages in the C family. Here, Swift diverges from C and > resembles Go. I raised this point some time ago and was told in no > uncertain terms by the core team that it was intentional and that they were > satisfied with the result. > Is the core team talking only for bitwise operators or all of them? > > >> >> On Wed, Jun 15, 2016 at 11:23 AM Антон Жилин <antonyzhi...@gmail.com> >> wrote: >> >>> What do you think about arithmetic and bitwise operators? Arithmetic and >>> casting? Should they have defined precedence? >>> >>> - Anton >>> >>> 2016-06-15 21:17 GMT+03:00 Saagar Jha <saagarjh...@gmail.com>: >>> >>>> We’ve talked about how expressions like `a + b * c / d` aren’t >>>> ambiguous because they are borrowed, in this case from math. The same thing >>>> applies to the ternary conditional: `a ? b : c + x + y`-it too is borrowed >>>> (from the C-type languages) and behaves likewise. There is no need for >>>> parentheses-the only people who will think this is ambiguous is those who >>>> haven’t been introduced to it before. IMHO, requiring parentheses would be >>>> *more* ambiguous because you’re breaking precedent, people already >>>> know how it should work, without parentheses. Forcing them to use it breaks >>>> their prior knowledge. We don’t need to hand-hold people who *know* how >>>> it works. For those who don’t know, it’s a simple matter of reading it up >>>> (which they would be doing anyways to learn about it!) >>>> >>>> As for nil coalescing, it’s visually similar to the ternary operator >>>> and as such has similar behavior. Having a reminder in the Swift guide >>>> about its precedence should be enough, once users have learned it they >>>> don’t need to be reminded every time they use it through a warning. >>>> >>>> >>>> On Wed, Jun 15, 2016 at 11:00 AM Xiaodi Wu via swift-evolution < >>>> swift-evolution@swift.org> wrote: >>>> >>>>> Maybe wise to wait to see if that proposal is accepted. FWIW, my last >>>>> interaction with the core team on operator precedence suggested that they >>>>> believed that they had arrived at the correct relative precedence values >>>>> and were not receptive to changing them. >>>>> On Wed, Jun 15, 2016 at 12:54 Антон Жилин <antonyzhi...@gmail.com> >>>>> wrote: >>>>> >>>>>> I wonder if it's worth it to start a new thread right now. >>>>>> We could start discussing, what precedence relationships between >>>>>> opeartors should be, even *before* that proposal is accepted. >>>>>> If it's rejected though, that discussion is going to trash bin. >>>>>> >>>>>> - Anton >>>>>> >>>>>> 2016-06-15 19:52 GMT+03:00 Антон Жилин <antonyzhi...@gmail.com>: >>>>>> >>>>>>> Back to associativity, I see nothing wrong with what a ?? b ?? c >>>>>>> does. Analogous constructions are found in Ruby, for example. Right >>>>>>> associativity exists so that we can do lazy evaluation, computing >>>>>>> fallback >>>>>>> values only when required. Nothing terrible, again. >>>>>>> >>>>>>> - Anton >>>>>>> >>>>>>> 2016-06-15 19:15 GMT+03:00 Xiaodi Wu <xiaodi...@gmail.com>: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution < >>>>>>>> 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? >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 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>>: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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>>>: >>>>>>>>>> >>>>>>>>>> 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>> >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>> -- >>>> -Saagar Jha >>>> >>> >>> -- >> -Saagar Jha >> > -- -Saagar Jha
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution