> On Mar 31, 2016, at 11:43 PM, Fabian Ehrentraud 
> <[email protected]> wrote:
> 
> Great to hear IUOs losing ground :-)
> 
> Might adding additional compiler warnings as described in SR-104 accompany 
> the implementation of this proposal well?
> https://bugs.swift.org/browse/SR-104 <https://bugs.swift.org/browse/SR-104>
This is definitely related, but orthogonal to SE-0054.  

Just MHO, but I think warning on every implicit unwrap would completely defeat 
the point of having the T! feature in the first place: if that were the model 
we wanted, we would just import unaudited pointers as optional.  Doing that has 
been extensively discussed and is not a good idea.

-Chris

> 
> Fabian
> 
> 
>> On 31.03.2016, at 18:43, Chris Lattner via swift-evolution 
>> <[email protected] <mailto:[email protected]>> wrote:
>> 
>> Proposal Link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md
>>  
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md>
>> 
>> The review of SE-0054 "Abolish ImplicitlyUnwrappedOptional type" ran from 
>> Mar 25…30, 2016. The proposal has been *accepted, pending implementation 
>> experience*:
>> 
>> There is generally positive feedback on the proposal, as it keeps the good 
>> behaviors of the existing T! type syntax (including support for importing 
>> un-nullability-audited APIs, support for 2-phase initialization patterns, 
>> etc) while dramatically reducing the confusion and surprise that they 
>> introduce as they trickle through type inference.  The core team sees 
>> significant value in having a simple and predictable model that can be 
>> explained concisely. 
>> 
>> That said, this is the sort of proposal that can have a profound impact on 
>> the actual experience using unaudited APIs.  The core team believes that the 
>> experience will be good, but we would like to get some experience moving a 
>> couple of existing projects (both low-level code that interacts with C, and 
>> an “App” project working with high level frameworks) to see what the impact 
>> is in practice.  If something unexpected comes up, we will revisit this, and 
>> potentially reject it later.  Chris Willmore is working on an implementation 
>> of this now, so we should know in the next week or two.
>> 
>> Thank you to Chris Willmore for driving this forward!
>> 
>> -Chris Lattner
>> Review Manager
>> _______________________________________________
>> 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

Reply via email to