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

[Tony Allevato]

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.


On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution <
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>> 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>
> >     https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> >
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160517/b06dea4f/attachment.html>