[swift-evolution] Optional Argument Chaining

[Yuta Koshizawa]

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 at swift.org>:
>
>
> On Dec 11, 2017, at 2:41 PM, Jared Khan via swift-evolution
> <swift-evolution at 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 at 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 at swift.org> wrote:
>>
>>
>> > 12 Dec. 2017 02:58 Jared Khan <jaredkhan at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>