I’d agree with that. That’s consistent with the “left-to-right and short-circuit at first failure” approach.
> On 12 Dec 2017, at 15:33, Yuta Koshizawa <ko...@koherent.org> wrote: > > I think evaluating them in the same way as `try` calls is consistent. > > ``` > f(g()?, h()?, i(), j()?)? > // like > try f(try g(), try h(), i(), try j()) > ``` > > ``` > foo(bar(x()?)) + y()? > // like > foo(bar(try x())) + (try y()) > ``` > > -- > Yuta > > > 2017-12-12 7:42 GMT+09:00 Slava Pestov via swift-evolution > <swift-evolution@swift.org>: >> >> >> On Dec 11, 2017, at 2:41 PM, Jared Khan via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> I missed the previous threads! I’ve found one of the relevant threads here: >> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024201.html >> >> Thanks for this important point. >> >> If you were to write this logic out by hand then you would short-circuit it >> and this is analogous to current chaining behaviour so to me evaluating left >> to right (as Swift usually does) and stopping at the first failed unwrap >> would make sense. I wouldn’t necessarily say it’s intuitive but I don’t >> think it’s really less intuitive than the current chaining behaviour. >> >> >> I think it gets confusing when you have multiple levels of nested >> expressions, eg >> >> foo(bar(x?)) + y? >> >> Slava >> >> >> Jared >> >> On 11 Dec 2017, at 19:28, Xiaodi Wu via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> This topic has been discussed at least two and maybe more times in the >> past.. It’s hard for me to post links at the moment, but it should be >> possible to find on Google. >> >> One major challenge to this idea, for which no satisfactory answer has been >> achieved after all these years, is the following issue: >> >> f(g()?, h()?, i(), j()?)? >> >> If g() evaluates to nil, is h() called or not? How about i(), which is not >> failable? Since any function or property access can have side effects, in >> what order are the arguments evaluated, and how does one reason about this >> code flow? >> >> To my mind, in the absence of an intuitive answer to the above—which does >> not appear to be possible—this idea is not feasible. >> On Mon, Dec 11, 2017 at 12:34 Magnus Ahltorp via swift-evolution >> <swift-evolution@swift.org> wrote: >>> >>> >>>> 12 Dec. 2017 02:58 Jared Khan <jaredk...@me.com> wrote: >>>> >>>> 2. It felt natural to me. It’s analogous to the existing optional >>>> chaining scenarios and composes nicely. I think it’s about as >>>> understandable >>>> as existing chaining, a newbie would have to look it up to discover its >>>> meaning. What are your thoughts on this particular syntax (ignoring 3. >>>> momentarily)? Hopefully others in this thread can share their views too. >>> >>> Chaining methods is linear, while nesting fills a similar purpose when we >>> use function calls. This of course affects the way existing Swift code is >>> written, but that is something we have to live with if we want to use >>> familiar syntax patterns. However, I think we have to consider this >>> difference in this case, since the syntax becomes more convoluted. Your >>> suggestion is definitely not as easy to read as the optional chaining >>> syntax, and maybe it can't be. >>> >>>> As for how common I’d expect it to be, it’s something I’ve run into >>>> myself a few times. Again, I hope members of this list can give their view >>>> on if this would be useful to them. >>> >>> I don't have any real examples, but I certainly think that I have run into >>> it, so I'm quite open to solving the problem. For me, it is probably only a >>> matter of finding a syntax that is acceptable. >>> >>>> 3. I’m not entirely sure what the grammar situation is yet but afaik ‘?’ >>>> has never been available as a postfix operator. Perhaps I’m missing your >>>> point, could you demonstrate where it is allowed? >>> >>> I did not expect that you would be able to answer that, it was more a >>> question directed to people who are more connected to the inner workings of >>> the parsing of Swift than I am. It is not allowed, but the error message is >>> not the one I expect, something that gives me a hint that it does have some >>> meaning early in the parsing. >>> >>> /Magnus >>> >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> 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 >> _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution