> 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 > > <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 <mailto: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 <mailto:swift-evolution@swift.org>> wrote: >> >> > 12 Dec. 2017 02:58 Jared Khan <jaredk...@me.com <mailto: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 <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <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
