[swift-evolution] [Idea] if let value!

[Matthew Johnson]

> On May 17, 2016, at 10:50 AM, Vladimir.S <svabox at gmail.com> wrote:
> 
> Could you clarify how to use `if case` to achieve the same target as proposed `if let value!` ?
> (btw, probably `if let value? {..}` will be better)

You don’t get the same implicit match that this idea proposes, but you do get the full power of pattern matching.  And you get to use the ? pattern. 

let i: Int? = 42
if case let i? = i {
}

The differences in the suggestion here is to allow you to drop case and implicitly match on the value currently bound to the name in the pattern, rebinding using the pattern if a match happens.

If people really want to pursue further sugar here I think it would be worthwhile to explore a direction that hasn’t already been debated extensively.  That is why I suggested thinking about `if unwrap`.  That said, I really don’t think current state is too bad.  It’s definitely not worth expending community energy on this when we clearly have more important things to focus on (like completing generics and ABI).

> 
> On 17.05.2016 18:18, Matthew Johnson wrote:
>> 
>>> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution
>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> While I've sometimes (early on) wished for a shorter-hand syntax for that
>>> construct, I've never been able to think of something that I thought was
>>> better. I've gotten to the point where I don't particularly mind it anymore.
>>> 
>>> Regarding the exclamation point specifically, seeing one of those in an
>>> expression context says to me "this thing will die horribly if it is
>>> nil/throws an error". Using it in this context where that's not the case
>>> would probably go against users' expectations.
>> 
>> Agree.  If we are going have syntax similar to pattern matching it should
>> be the same as pattern matching.  This would mean using ‘?' rather than
>> ‘!’.  However, we already have generalized pattern matching with `if case`
>> for that.  This topic has been debated extensively.
>> 
>>> 
>>> 
>>> On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution
>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>    On 17.05.2016 16:51, Johan Jensen wrote:
>>>     > This was one of the first and most commonly suggested ideas, when
>>>    the Swift
>>>     > Evolution mailing list first started.
>>>     > Chris Lattner sums it up
>>>     >
>>>    <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>
>>>     > in one of those threads:
>>>     >
>>>     >> This is commonly requested - the problem is that while it does help
>>>     > reduce boilerplate, it runs counter to the goal of improving clarity.
>>>     >
>>>     > — Johan
>>> 
>>>    Oh, thank you for letting this know.
>>> 
>>>    Well, I totally disagree with Chris. And as soon as there was no
>>>    'official'
>>>    proposal and 'official' decision, I'd like to discuss this more.
>>> 
>>>    I saw a lot of code like
>>>    if let mySomeValue = mySomeValue {} in sources and even in books.
>>>    Plus, I really believe that
>>>    if let mySomeValue! {..} is better in any way: readability, less
>>>    space for
>>>    errors(when you need to repeat the same name) etc
>>> 
>>>    FWIW, I suggest more explicit variant:
>>>    if let value! {...} // with exclamation mark
>>>    In that "old" proposal there was `if let value {...}`, was not so clear.
>>> 
>>>    I can't accept an argument that you can use another name - as usually
>>>    'good' name is already 'crafted' for the instance and you want to use
>>>    it in
>>>    next code.
>>>    Otherwise, we need a 'best practice' to name optional variables with some
>>>    prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =
>>>    mySomeValueOpt` will have a sense. But as I understand, we don't want to
>>>    use such approach.
>>>    Additionally, when you shadow optional value with same name - you are
>>>    *protecting* yourself from using optional value inside block of unwrapped
>>>    code. IMO it is a good idea.
>>>    And want we or don't want, we already have this practice widely. So I
>>>    believe this(my) proposal will improve the code.
>>> 
>>>    I'd like to get opinion of the community regarding this feature.
>>> 
>>>    On 17.05.2016 16:51, Johan Jensen wrote:
>>>    > This was one of the first and most commonly suggested ideas, when
>>>    the Swift
>>>    > Evolution mailing list first started.
>>>    > Chris Lattner sums it up
>>>    >
>>>    <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>
>>>    > in one of those threads:
>>>    >
>>>    >> This is commonly requested - the problem is that while it does help
>>>    > reduce boilerplate, it runs counter to the goal of improving clarity.
>>>    >
>>>    > — Johan
>>>    >
>>>    > On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution
>>>    > <swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>    <mailto:swift-evolution at swift.org
>>>    <mailto:swift-evolution at swift.org>>> wrote:
>>>    >
>>>    >     It is common to shadow optional value name with unwrapped value
>>>    with
>>>    >     same name:
>>>    >
>>>    >     if let someGoodValue = someGoodValue {...}
>>>    >
>>>    >     What if we'll have a syntax to not repeat the variable name to
>>>    achieve
>>>    >     the same target:
>>>    >
>>>    >     if let someGoodValue! {...}
>>>    >
>>>    >     What do you think?
>>>    >     _______________________________________________
>>>    >     swift-evolution mailing list
>>>    >     swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>    <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>>>    >     https://lists.swift.org/mailman/listinfo/swift-evolution
>>>    >
>>>    >
>>>    _______________________________________________
>>>    swift-evolution mailing list
>>>    swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>    https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>