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 < [email protected]> 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 > > <[email protected] <mailto:[email protected]>> 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 > > [email protected] <mailto:[email protected]> > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
