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

Xiaodi Wu xiaodi.wu at gmail.com
Tue Aug 16 09:41:52 CDT 2016 

I have already explained why your proposal is not at all like optional
chaining. Your proposal hides complicated control flow changes, but
optional chaining does not.

It does not do you any good to argue that "most people won't nest functions
inside functions". First of all, that's an unbelievable claim. Second of
all, computed properties can have side effects, since they are essentially
functions under the hood. Have you never referred to `foo.bar` inside a
function call? You literally cannot know if a property is computed,
potentially with side effects, unless you inspect the source code. Thus, a
programmer cannot know if they "choose to nest functions inside functions".
It does not matter if they are a genius.
On Tue, Aug 16, 2016 at 09:30 Justin Jia <justin.jia.developer at gmail.com>
wrote:

> On Aug 16, 2016, at 9:52 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> That is indeed idiomatic Swift. You will find it frequently in code
> written in the language, and in other discussions it has been said (and at
> one point, directly in reply to me) that it is the preferred way of
> expressing this check.
>
>
> Let me restate myself. I *agree* that being explicit is the preferred way.
> For example, `guard x else return` is not allowed. `guard x else { return
> }` is the preferred way. There is nothing wrong with brackets! However,
> things are not always that easy. `let x = 1` is the preferred way. `let x:
> Int = 1` is unnecessary.
>
> Imagine that type interference does not existed in Swift and somebody
> proposed it. I bet some people would reply: “I prefer to explicit specify
> the type. Being explicit is more important.”.
>
> This spelling is superior to your proposal for a reason you've already
> stated yourself in a message just before this one: in code, execution
> proceeds from top to bottom unless a control flow statement changes that.
> Control flow statements use braces to demarcate sections of code that are
> executed in alternative orders. It is the crux of my argument that your
> proposal is unworkable precisely because it sugars a complicated change in
> control flow and removes the braces.
>
>
> You didn’t understand me… I was arguing that, most of the time, checking
> if a variable is nil *does not need to use* control flow statements. Thank
> you for keeping the discussion. But maybe you should read my email more
> carefully next time? This just mimic `object?.method`.
>
> Earlier, you said that you were initially not aware of the complexity of
> the short circuiting issue. That is a good demonstration of my point: if
> the originator of the proposal could not anticipate the complexity there, a
> reader who sees your proposed sugar in code would certainly be entirely
> unaware of the complexity of control flow hidden behind it. That is
> entirely a non-starter, because it shows unambiguously that code that uses
> this sugar would be incomprehensible to the reader. (By contrast, a reader
> of foo?.bar()?.baz() cannot help but recognize that if foo is nil,
> nil.bar() is notionally a noop.)
>
>
> No. What I said is a good demonstration of my point. It is normal to write
> `foo?.bar()?,baz()`. It is not normal to write `foo(bar()?, baz()?)`. Most
> people won’t nest functions inside functions. They won’t even realize that
> the problem exists. If they choose to nest functions with side effects,
> they can always check the docs or use Stack Overflow. Short-circuiting from
> left to right is intuitive enough that programmers will remember it after
> they checked the docs once. Programmers are not that stupid.
>
> 1. I think `if let` is boilerplate. (My argument: otherwise we won’t even
> have `object?.method`).
> 2. My proposed solution is intuitive enough for most simple use cases. (My
> argument: above paragraph).
> 3. My proposed solution is easy to learn and remember for advanced use
> cases. (My argument: above paragraph).
>
> Sincerely,
> Justin
>
> On Tue, Aug 16, 2016 at 00:01 Justin Jia <justin.jia.developer at gmail.com>
> wrote:
>
>> I see a pattern of myself writing code like this now:
>>
>> ```
>> func foo(x: Int?) -> Int? {
>>     guard x = x else { return nil }
>>     /* normal function */
>> }
>> ```
>>
>> This is even worse than the x? syntax. But sometimes I have no other
>> choice. Most of my functions are without side effects and… I don’t want to
>> write if let x = x every time I call this function.
>>
>> On Aug 16, 2016, at 12:56 PM, Justin Jia <justin.jia.developer at gmail.com>
>> wrote:
>>
>>
>> On Aug 16, 2016, at 1:51 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>> On Mon, Aug 15, 2016 at 12:31 PM, Justin Jia <
>> justin.jia.developer at gmail.com> wrote:
>>
>>>
>>> Since you mentioned do and defer:
>>>
>>> ```
>>> func foo(wantsToBreak: Bool) {
>>>     out: do {
>>>         defer { print("Hello, world!") }
>>>         guard wantsToBreak else { break out }
>>>     }
>>>     print("End of function.")
>>> }
>>>
>>> foo(wantsToBreak: true) // Output: Hello, world!\nEnd of function.
>>> foo(wantsToBreak: false) // Output: Hello, world!\nEnd of function.
>>> ```
>>>
>>> Do you think this is confusing?
>>>
>>
>> No, I don't. But I also don't see why you would put `defer` inside `do`
>> like that. `defer` and `guard` can be used profitably without nesting
>> inside blocks.
>>
>>
>>
>> Because I don’t want `defer` to execute outside do block. Let me give you
>> a simplified example: I wanted to print error for all early exits except
>> normal return (reaches last line). I would like to use defer otherwise I
>> need to write `else { print(error); return }` for all guards. The intuitive
>> way of achieving this for me was to nest defer inside do blocks. But it
>> turned out that defer will be executed even if you choose to break a block.
>> I’m not arguing this is a bad design decision. My point is: sometimes
>> non-intuitive design decisions are non-avoidable.
>>
>>
>> At least it confused me in the fast. However, defer is still very useful.
>>>
>>> Even if I choose to use guard, defer and do, it will still look like the
>>> one with `if let`. Lots of blocks. The code should be straightforward
>>> without any brackets.
>>>
>>
>> Huh? I don't buy this argument at all. You don't like the look of `{ }`,
>> so you are proposing new sugar using `?`--is that what you're claiming?
>> This sounds to me like the same motivation as that behind early suggestions
>> to move to a Python-like syntax.
>>
>>
>>> See this example (since it’s a lot of code I rendered a PDF).
>>>
>>
>> I don't see the motivation in this example. Why wouldn't you just move
>> the code to update `cell.heading` right after you guard that `imageName` is
>> not nil?
>>
>>
>>
>> I already explained why. It was just a naive example. In real life
>> methods can be a lot more complicated than my example. It’s really bad if
>> your code will fail unless it follows the same exact order. We need to
>> modify our code everyday, and most of the time we are working on code that
>> is not even written by ourselves. If you scan through methods with name
>> like updateCell, intuitively, you will think the order of the code will not
>> matter. And it shouldn’t! It is really easy to make mistakes with guard
>> statement because the order matters here. IMO, guard is only useful if we
>> place it at the beginning of the function—for all or nothing.
>>
>> Why we chose to use brackets and indentation? Because they can warn us
>> that the behavior of the code will change. Either the outcome will vary
>> (if) or the code will be executed for more than one time (for). Checking an
>> object if is nil doesn’t always belong here. Using `if let` is not being
>> explicit. It’s boilerplate. A not-so-good fix for the side effect of
>> optionals. Most of the time, we want the flow to be “flat”. That’s why
>> swift supports `guard` and `object?.method`. If you think `foo(x?)` is not
>> important, do you think `guard` and `object?.method` are also not important?
>>
>> I understand that Swift is designed to be explicit. I also agree with it.
>> But I saw an unhappy trend in the mailing list: "this is not explicit
>> enough" can be used to argue against anything. Shall we remove
>> @autoclosure? Shall we remove trailing closures? Shall we remove
>> `object?.method`?
>>
>> On Aug 16, 2016, at 1:16 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>
>>> On Mon, Aug 15, 2016 at 12:07 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>
>>>> On Mon, Aug 15, 2016 at 11:43 AM, Justin Jia <
>>>> justin.jia.developer at gmail.com> wrote:
>>>>
>>>>> I believe the core team has considered 99% of the ideas in the mailing
>>>>> list in the past, but it doesn’t mean we can’t discuss it, right?
>>>>>
>>>>
>>>> No, it certainly doesn't! I'm saying that you haven't come up with a
>>>> solution to a known problem with the idea.
>>>>
>>>>
>>>>>
>>>>> Assuming we have the following declaration:
>>>>>
>>>>> ```
>>>>> func foo(a: Int, b: Int?, c: Int, d: Int?) -> Int
>>>>> ```
>>>>>
>>>>> For this:
>>>>>
>>>>> ```
>>>>> let z = foo(a: f1(), b: f2()?, c: f3(), d: f4()?) // z becomes optional
>>>>> ```
>>>>>
>>>>> We have a few different “possible solutions”:
>>>>>
>>>>> 1. Short-circuiting from left to right. This is equivalent to:
>>>>>
>>>>> ```
>>>>> var z: Int? = nil
>>>>> let a = f1()
>>>>> guard let b = f2() else { return }
>>>>> let c = f3()
>>>>> guard let d = f4() else { return }
>>>>> z = foo(a: a, b: b, c: c, d: d)
>>>>> ```
>>>>>
>>>>> 2. Short-circuiting from left to right for optionals. Then evaluate
>>>>> non-optional parameters. This is equivalent to:
>>>>>
>>>>> ```
>>>>> var z: Int? = nil
>>>>> guard let b = f2() else { return }
>>>>> guard let d = f4() else { return }
>>>>> let a = f1()
>>>>> let c = f3()
>>>>> z = foo(a: a, b: b, c: c, d: d)
>>>>> ```
>>>>>
>>>>> 3. Do not short-circuiting.
>>>>>
>>>>> ```
>>>>> var z: Int? = nil
>>>>> let a = f1()
>>>>> let optionalB = f2()
>>>>> let c = f3()
>>>>> let optionalD = f4()
>>>>> guard let b = optionalB else { return }
>>>>> guard let d = optionalD else { return }
>>>>> z = foo(a: a, b: b, c: c, d: d)
>>>>> ```
>>>>>
>>>>> Like I said before, I agree that there is no intuitive solution to
>>>>> this problem. However, I'm still not convinced that this feature is *not
>>>>> important*.
>>>>>
>>>>> Thank you for pointing out the problem to me. I didn't notice it at
>>>>> the time I wrote my first email. I really appreciate that. However, instead
>>>>> of saying I don't know which is the best solution so let's assume the core
>>>>> team made the right decision, we should discuss whether 1, 2, 3 is the best
>>>>> solution. Or you can convince me we don't *need* this feature.
>>>>>
>>>>
>>>> I'm going to convince you that 1, 2, and 3 are all bad solutions. Thus,
>>>> this feature won't fly.
>>>> The fundamental issue is that having this sugar means that I can no
>>>> longer reason about the order in which code is executed. An innocuous
>>>> statement such as `print(a(), b(), c(), d())`, once you mix in your
>>>> proposed `?` syntax with some but not all of these function calls, might
>>>> have d() executed before a(), after a(), or not at all. This is greatly
>>>> damaging to the goal of writing clear, understandable code.
>>>>
>>>>
>>>>>
>>>>> Back to the original topic.
>>>>>
>>>>> I spent some time thinking and changed my mind again. I think solution
>>>>> 1 is most reasonable. It is consistent with if statements. Instead of
>>>>> treating it as sugar for `if let`, we can treat it as sugar for `guard`,
>>>>> which is much easy to understand and remember.
>>>>>
>>>>> -
>>>>>
>>>>> Below is the reason why I think this feature is important (quoted from
>>>>> another email).
>>>>>
>>>>> The problem with `if let` is you need to call the function inside { }.
>>>>>
>>>>> ```
>>>>> /* code 1 */
>>>>> if let x = x, let y = y {
>>>>>     /* code 2, depends on x and y to be non-optional */
>>>>>     let z = foo(x, y)
>>>>>     if let z = z {
>>>>>         bar(z)
>>>>>     }
>>>>>     /* code 3, depends on x and y to be non-optional */
>>>>> }
>>>>> /* code 4 */
>>>>> ```
>>>>>
>>>>> I can't use `guard` for this situation because guard will force me to
>>>>> leave the entire function.
>>>>>
>>>>
>>>>> ```
>>>>> /* code 1 */
>>>>> guard let x = x, y = y else { return }
>>>>> /* code 2, depends on x and y to be non-optional */
>>>>> guard let z = foo(x, y) else { return }
>>>>> bar(z)
>>>>> /* code 3, depends on x and y to be non-optional */ <- This won't
>>>>> execute if z is nil
>>>>> /* code 4 */ <- This won't execute if x, y or z is nil
>>>>> ```
>>>>>
>>>>
>>>> Then surround it with a do block.
>>>>
>>>> ```
>>>> out: do {
>>>>   guard foo else { break out }
>>>>   guard bar else { break out }
>>>>   /* other code */
>>>> }
>>>> ```
>>>>
>>>
>>> Or, more idiomatically, since your use case is that you want /* code 4
>>> */ to be executed no matter what, while everything else depends on x and y
>>> not being nil:
>>>
>>> ```
>>> defer { /* code 4 */ }
>>> guard let x = x, let y = y else { return }
>>> /* code 2 */
>>> /* code 3 */
>>> ```
>>>
>>>
>>>>> What I really want is some like this:
>>>>>
>>>>> ```
>>>>> / * code 1 */
>>>>> let z = foo(x?, y?)
>>>>> /* code 2, depends on x and y to be non-optional, use x? and y? */
>>>>> bar(z?)
>>>>> /* code 3, depends on x and y to be non-optional, use x? and y? */
>>>>> /* code 4 */
>>>>> ```
>>>>> This is much easier to read. Sometimes people choose to use `guard` to
>>>>> avoid `{ }`, which usually lead to code could easily get wrong (like the
>>>>> second example).
>>>>>
>>>>> Sincerely,
>>>>> Justin
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Aug 15, 2016, at 11:41 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>>>
>>>>> What do you mean, limited to variables? What about a computed
>>>>> property? You will have the same problem.
>>>>>
>>>>> I'm not sure where you want to go with this, given that the core team
>>>>> has considered the same idea in the past and found these issues to have no
>>>>> good solution.
>>>>>
>>>>> On Mon, Aug 15, 2016 at 04:56 Justin Jia <
>>>>> justin.jia.developer at gmail.com> wrote:
>>>>>
>>>>>> IMO I don't this bar should be evaluated unless we decide if let can
>>>>>> accept non-optional values.
>>>>>>
>>>>>> Actually, what if we allow if let to accept non-optional values?
>>>>>>
>>>>>> I agree this is confusing at the beginning. But people who are not
>>>>>> familiar with the detail design can avoid this situation easily. People who
>>>>>> are familiar with the design can adopt it quickly. Sometimes, this is
>>>>>> unavoidable.
>>>>>>
>>>>>> Btw, do you think this is still something nice to have if we limit
>>>>>> this syntax to only variables?
>>>>>>
>>>>>> On Aug 15, 2016, at 4:59 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>>>>
>>>>>> 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/20160816/2a7b3886/attachment.html>

More information about the swift-evolution mailing list