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

Xiaodi Wu xiaodi.wu at gmail.com
Mon Aug 15 03:55:49 CDT 2016


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. If short-circuiting works
left-to-right, then the answer is no. 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/d87885e2/attachment.html>


More information about the swift-evolution mailing list