> On Dec 19, 2015, at 5:12 PM, Dennis Lysenko via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Cihat, if either of the two you proposed I would prefer "let foo?" as the
> bang (!), outside of logical negation, carries a meaning of "this is
> dangerous and something could go wrong at runtime here". Evidenced by its
> only other uses--try!, force-unwrapping, and implicitly unwrapped optionals.
>
> However, you may be interested in the last email Chris sent in this chain
> with regards to shortening it to just "let foo":
>
> "This is commonly requested - the problem is that while it does help reduce
> boilerplate, it runs counter to the goal of improving clarity."
>
> He's got a point; "if let foo = bar" makes sense in a way, but just "if let
> foo" is a bit nonsensical to me when I take my mind outside of the narrow
> swift mindset I tend to get into. This extends to decorating the foo with a
> question mark or a bang, imo.
But, “if let foo = foo {}” makes no sense to anybody but people familiar with
swift already. Dropping the redundancy really doesn’t harm much because you’ll
first have to learn what “let” is doing; once you know what “let” is doing “if
let foo {}” is fairly clear.
>
> On Sat, Dec 19, 2015 at 7:02 PM Cihat Gündüz <swift-evolution@swift.org
> <mailto:swift-evolution@swift.org>> 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
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
>>
>>>
>>> On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution
>>> <swift-evolution@swift.org <mailto: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 <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
https://lists.swift.org/mailman/listinfo/swift-evolution
