[swift-evolution] Please remove obscure "!" requirements for implicitly unwrapped optionals

[Jon Shier]

	I can’t answer for Per, but, at least in my iOS and OS X programming, I often find myself creating IUOs in view controller to represent properties that I’m guaranteed to have set before viewDidLoad, but don’t want a custom initializer, due to the pain of multiple required init methods. So while my IUO usage is perfectly safe, they’re rather awkward to use.
	That said, I’d have to see a specific proposal to tell if it’s any better for my usage than IUOs.


Jon Shier

> On Dec 4, 2015, at 7:04 PM, Chris Lattner <clattner at apple.com> wrote:
> 
>> 
>> On Dec 4, 2015, at 1:18 PM, Per Melin <p at greendale.se <mailto:p at greendale.se>> wrote:
>> 
>> On Fri, Dec 4, 2015 at 1:03 AM, Amir Michail <a.michail at me.com <mailto:a.michail at me.com>> wrote:
>> 
>> I really don’t like having to put the ! suffix in boolean contexts:
>> 
>> To be explicit:
>> 
>>     let a: Bool! = false
>> 
>>     if a == false { }  // Works as expected
>> 
>>     if !a { }  // Works as expected
>> 
>>     if a { }   // "error: optional type 'Bool!' cannot be used as a boolean; test for '!= nil' instead"
>> 
>> Xcode "fixes" the last line like this:
>> 
>>     if (a != nil) { }
> 
> Huh ok.  Out of curiosity, why are you using IUOs for this?  I’m interested in (continuing to ) dramatically reduce the prevalence of IOUs in code (eliminating the need to use them), and reduce their power in various ways.  IUOs are one of the biggest sources of surprising behavior in Swift, and while they were a necessary feature to start with, their importance is going down over time.
> 
> -Chris
> 
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151204/13ca52ff/attachment-0001.html>