[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