I've always thought that,
if let foo = foo? {
}
makes more sense than
if let foo = foo {
}
as the ? indicates that you are unwrapping the optional and then assigning it
to the new variable
> On Dec 19, 2015, at 7:02 PM, Cihat Gündüz via swift-evolution
> <[email protected]> wrote:
>
> I’ve only read the last couple of posts but has anybody already suggested
> using something like this:
>
> if let foo! {
> // code that uses foo
> }
>
> People already know that the ! is unwrapping a value and that let is defining
> a new constant. So why not combine those two?
> Alternatively it could also be:
>
> if let foo? {
> // code that uses foo
> }
>
> What do you think?
>
> – Cihat
>
>>> Am 19.12.2015 um 23:43 schrieb Dave Abrahams via swift-evolution
>>> <[email protected]>:
>>>
>>>
>>> On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution
>>> <[email protected]> wrote:
>>>
>>> I was going to suggest something similar (a hard naming problem also):
>>>
>>> if has foo {
>>> // foo is now unwrapped and non-optional
>>> }
>>>
>>> guard has foo else { return }
>>>
>>> Does the same thing as `let foo = foo` in practice, but places it in a
>>> somewhat different mental model. Instead of unwrapping and immediately
>>> assigning to a new constant with the same name (which just looks kind of
>>> silly, like some magic voodoo ritual), it sort of asserts that we “have”
>>> foo (i.e. it’s not nil), and therefore from that point it can just be
>>> treated as non-optional.
>>>
>>> IMHO this, although introduces a new keyword, makes more sense than trying
>>> to reuse “let” in a context where it seems nonsensical. Perhaps this would
>>> be closer to Swift’s goals, by reducing very common boilerplate, but
>>> without harming clarity in a way adding a new meaning to “let” would.
>>>
>>> Curious to hear Chris Lattner’s opinion :-)
>>
>> IANACL (I am not a Chris Lattner) but, FWIW, several of us are uncomfortable
>> with the idea that a single declared property might have different static
>> types in different regions of code.
>>
>>>
>>> — Radek
>>>
>>>> On 19 Dec 2015, at 21:31, Dennis Lysenko via swift-evolution
>>>> <[email protected]> wrote:
>>>>
>>>> What if we made the keyword "unwrap"?
>>>>
>>>> if unwrap someViewController {
>>>> // now there is a shadowing nonoptional (unwrapped) variable of the same
>>>> name only within this scope, boiling down to simple syntactic sugar for
>>>> optional binding and it is fairly clear.
>>>> }
>>>>
>>>>
>>>>> On Sat, Dec 19, 2015, 1:31 PM Kevin Wooten via swift-evolution
>>>>> <[email protected]> wrote:
>>>>> As much fun as it to example with foo, I would argue the opposite when
>>>>> you use some real world variable names:
>>>>>
>>>>> if let someInterestingViewConroller = someInterestingViewConroller {
>>>>> }
>>>>>
>>>>> vs
>>>>>
>>>>> If let someInterestingViewConroller {
>>>>> }
>>>>>
>>>>> We know what let does and it should be enough to impart the necessary
>>>>> information for this statement.
>>>>>
>>>>> When it comes to newcomers I think you'd be hard pressed to find somebody
>>>>> who'd be able to understand either form without teaching; so not losing
>>>>> much there.
>>>>>
>>>>>
>>>>>> On Dec 19, 2015, at 10:01 AM, Chris Lattner via swift-evolution
>>>>>> <[email protected]> wrote:
>>>>>>
>>>>>>
>>>>>>> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution
>>>>>>> <[email protected]> wrote:
>>>>>>>
>>>>>>> I’ve had similar ideas to this. Instead of ditching the if let syntax
>>>>>>> altogether, another approach would be to use the existing name if no
>>>>>>> new name is given, so that this code:
>>>>>>>
>>>>>>> if let foo = foo { /* use foo */ }
>>>>>>>
>>>>>>> could become this code:
>>>>>>>
>>>>>>> if let foo { /* use foo */ }
>>>>>>>
>>>>>>> In both cases, foo is non-optional inside the braces. If you gave it
>>>>>>> another name with the if let syntax, that would work as it does today.
>>>>>>
>>>>>> Hi Jeff,
>>>>>>
>>>>>> This is commonly requested - the problem is that while it does help
>>>>>> reduce boilerplate, it runs counter to the goal of improving clarity.
>>>>>>
>>>>>> -Chris
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> [email protected]
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> [email protected]
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected]
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> -Dave
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
