i’ve run into this problem enough to wish this was a thing in Swift a lot, but when it comes to solutions, i think the proposed syntax just isn’t clear or easy to read, especially if there’s multiple layers involved.
On Mon, Dec 11, 2017 at 1:28 PM, 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