> On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution
> <swift-evolution@swift.org> 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
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>>
>>>> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
-Dave
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
