On Mon, Aug 15, 2016 at 3:55 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> On Mon, Aug 15, 2016 at 3:25 AM, Justin Jia via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> On Aug 15, 2016, at 4:09 PM, Charlie Monroe <char...@charliemonroe.net> >> wrote: >> >> The example above was to better demonstrate the problem with *when* to >> evaluate the latter argument. Why should both arguments be evaluated >> *before* the if statement? If both calls return Optionals, >> >> if let x = bar(42), y = baz(42) { ... } >> >> is how would I write it without the suggested syntax - baz(42) will *not* >> be evaluated if bar(42) returns nil. Which bears a question why would >> >> foo(bar(42)?, baz(42)?) >> >> evaluate both arguments even if the first one is nil, making it >> incosistent with the rest of the language? >> >> >> I see your point. I understand that maybe 1/2 of the people think we >> should evaluate both arguments and 1/2 of the people think we should only >> evaluate the first argument. >> >> I changed my idea a little bit. Now I think you are right. We should only >> evaluate the first argument in your example. It’s not only because of >> inconsistent, but also because the language should at least provide a way >> to “short-circuit” to rest of the arguments. >> >> If they want to opt-out this behavior, they can always write: >> >> ``` >> let x = bar(42) >> let y = baz(42) >> foo(x?, y?) >> ``` >> > > Well, that was just the easy part. Now, suppose bar is the function that > isn't optional. > > ``` > foo(bar(42), baz(42)?) > ``` > > Is bar evaluated if baz returns nil? If you want this syntax to be sugar > for if let, then the answer is yes. > s/yes/no/ > If short-circuiting works left-to-right, then the answer is no. > s/no/yes/ (See? Confusing.) > This is very confusing, and there is no good intuitive answer. > > >> _______________________________________________ >> 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