> 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.
Thank you for the feedback, Dennis. That post you quote is amongst the ones I
read and it is even the reason I am suggesting these alternatives. Let me
explain my thinking behind my suggestions a bit. I agree with Chris that `if
let foo { /* code */ }` isn’t very readable mainly because there is no action
done on the `foo` like a `= bar` or something else. But I also had the thought
‚why do I need to type this twice, can’t this be optimized?‘ quite a few times
when I used `if let foo = foo { /* code */ }` in practice.
So that’s why I thought there must be a way. First I started with something
that contained the `=` sign also using the shorthand `x += 1` for `x = x + 1`
as an inspiration. That lead to things like these:
if let foo = _ { /* code */ }
if let foo = ! { /* code */ }
if let foo ?= _ { /* code */ }
if foo ?= foo { /* code */ }
if let foo ?= { /* code */ }
But being honest to myself I thought all of those were even less readable then
`if let foo { /* code */ }`. But once I dropped the `=` sign like in `if let
foo! { /* code */ }` I started to like the idea and still found it readable.
I generally read let like a ‚define constant with name‘ and a ! like ‚force
unwrap value‘ so I would read `let foo!` as ‚define constant with name and
force unwrap value`. But I agree that ? may be more correct which I read as
`try to unwrap value only continuing if unwrap succeeds` so `let foo?` would
read as `define constant with name and try to unwrap only continuing if unwrap
succeeds`.
So in conclusion to me `if let foo { }` isn’t readable but `if let foo? { }`
is. That is only my opinion though.
>
> On Sat, Dec 19, 2015 at 7:02 PM Cihat Gündüz <[email protected]
> <mailto:[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] <mailto:[email protected]>>:
>>
>>>
>>> On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution
>>> <[email protected] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[email protected]>> wrote:
>>>>
>>>>>
>>>>>> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution
>>>>>> <[email protected] <mailto:[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] <mailto:[email protected]>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> -Dave
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
