> On 15 Aug 2016, at 20:39, Xiaodi Wu via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> On Mon, Aug 15, 2016 at 2:29 PM, Tim Vermeulen <tvermeu...@me.com
> <mailto:tvermeu...@me.com>> wrote:
>
>> On 15 Aug 2016, at 21:27, Xiaodi Wu <xiaodi...@gmail.com
>> <mailto:xiaodi...@gmail.com>> wrote:
>>
>> On Mon, Aug 15, 2016 at 1:57 PM, Haravikk via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>> On 15 Aug 2016, at 13:44, Tim Vermeulen <tvermeu...@me.com
>>> <mailto:tvermeu...@me.com>> wrote:
>>>
>>>>> On 15 Aug 2016, at 08:02, Justin Jia via
>>>>> swift-evolution<swift-evolution@swift.org
>>>>> <mailto:swift-evolution@swift.org>(mailto:swift-evolution@swift.org
>>>>> <mailto:swift-evolution@swift.org>)>wrote:
>>>>> Hi!
>>>>>
>>>>> I don’t know if this has came up before. I tried to search though the
>>>>> mailing list but didn’t find any related threads.
>>>>>
>>>>> This is purely a syntactic thing (which I know it’s the lowest priority
>>>>> for Swift 4), but I think it’s an important one.
>>>>>
>>>>> Let’s say we have a struct with a function:
>>>>>
>>>>> ```
>>>>> struct Foo {
>>>>> func bar(x: Int)
>>>>> }
>>>>> ```
>>>>>
>>>>> We can use optionals:
>>>>>
>>>>> ```
>>>>> let foo: Foo? = nil
>>>>> let x = 1
>>>>> foo!.bar(x: x) // Able to compile, but will cause runtime error
>>>>> foo?.bar(x: x) // Able to compile, and won't cause runtime error
>>>>> ```
>>>>>
>>>>> However:
>>>>>
>>>>> ```
>>>>> let foo = Foo()
>>>>> let x: Int? = nil
>>>>> foo.bar(x: x!) // Able to compile, but will cause runtime error
>>>>> foo.bar(x: x?) // Won't compile
>>>>> ```
>>>>>
>>>>> I propose that we should allow `foo.bar(x: x?)`, which should be
>>>>> equivalent to:
>>>>>
>>>>> ```
>>>>> if let x = x {
>>>>> foo.bar(x: x)
>>>>> }
>>>>> ```
>>>>>
>>>>> What do you think?
>>>> I like the intent behind this, but personally I think it's not clear
>>>> enough. For me, putting the statement in a conditional as you've shown is
>>>> the better solution, as it's a lot clearer exactly what's going on.
>>>> Putting a question mark on a variable makes it look like something
>>>> specific to that variable, rather than preventing the entire statement
>>>> from executing.
>>>
>>> I get where you’re coming from, but how would people react if optional
>>> chaining wasn’t in the language yet and someone proposed it now? I know
>>> it’s not strictly the same thing, but it’s still a single question mark
>>> that prevents the whole statement from being executed. I think it would be
>>> met with a lot of resistance from people saying that being more explicit
>>> with `if let` is the way to go.
>>
>> True, but with optional chaining the position of the question mark makes it
>> a lot more clear where it stops, whereas in this proposal the question mark
>> seems a bit less intuitive since it's within the parenthesis yet affecting
>> the statement outside of it.
>>
>>>> There may be some alternatives though, for example, what about a shorthand
>>>> for the conditional like so:
>>>>
>>>> if let x? { foo.bar(x: x) }
>>>> if x? { foo.bar(x: x) } // even shorter?
>>>
>>> The alternatives you’ve come up with would only work if foo.bar doesn’t
>>> return anything. If it does return something, and you want to assign it to
>>> a variable, you have to declare the variable beforehand and it just becomes
>>> ugly. It’s then probably a better idea to use map/flatmap:
>>
>> Hmm, what about something involving the where keyword? Something like:
>>
>> let value = foo.bar(x: x) where x?
>>
>> Some people have queried the ability to use where in assignments before, as
>> another way to have a statement be nil if a condition isn't met, but in this
>> case the condition is that x is unwrapped (thus valid for the call). This
>> basically lets you use it like a "retroactive" conditional, it'd be nice to
>> get the same x? behaviour on for loops anyway (letting you unwrap values
>> that way, and maybe test them too).
>>
>> `let value = (x == nil) ? nil : foo.bar(x: x)` isn't so bad, is it?
>
> In my opinion, it is.
>
> It certainly isn't much longer, and its meaning is clear to anyone with a
> basic grasp of Swift. What makes it bad, in your opinion?
>
> And you’d even need to write `foo.bar(x: x!)`, right?
>
> You would. That's my bad.
Forgot about the ternary conditional!
For the force unwrapping, that's something that could be avoided in future by
type narrowing; just as we currently can't do:
if value is String { value.somethingUniqueToString() } // Must cast
first or use if let value = value as? String
Doing the same for optionality would allow force unwrapping to be removed in
future; I find having to use force unwrapping when I know I don't need to
annoying, but it's hardly much of an inconvenience to be sure of what's going
on._______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
