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. > > 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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution