[swift-evolution] [Idea] Use optionals for non-optional parameters

Xiaodi Wu xiaodi.wu at gmail.com
Mon Aug 15 03:59:04 CDT 2016


On Mon, Aug 15, 2016 at 3:55 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> On Mon, Aug 15, 2016 at 3:25 AM, Justin Jia via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> On Aug 15, 2016, at 4:09 PM, Charlie Monroe <charlie at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160815/35d5c313/attachment.html>


More information about the swift-evolution mailing list