> On May 2, 2016, at 3:43 PM, Joe Groff <jgr...@apple.com> wrote:
>
>
>> On May 2, 2016, at 2:45 PM, Chris Lattner <clatt...@apple.com> wrote:
>>
>> On Apr 29, 2016, at 3:00 PM, Joe Groff via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>> I’d like to propose the following changes:
>>>
>>> • Dynamic casts as?, as! and is should no longer perform bridging
>>> conversions between value types and Cocoa classes.
>>> • Coercion syntax as should no longer be used to explicitly force
>>> certain bridging conversions.
>>> • To replace this functionality, we should add initializers to bridged
>>> value types and classes that perform the value-preserving bridging
>>> operations.
>> +1. I think that this will lead to a much cleaner and more predictable set
>> of rules. It will probably also define away a ton of bugs in the compiler
>> and runtime.
>>
>>
>>
>>> NSError bridging can also be extracted from the runtime, and the same
>>> functionality exposed as a factory initializer on NSError:
>>>
>> I think that this proposal is overall really great, but what does it do to
>> the “catch let x as NSError” pattern? What is the replacement? If the
>> result is ugly, we may have to subset out NSError out of this pass, and
>> handle it specifically with improvements to the error bridging story.
>>
>
> If we remove the bridging magic and do nothing else, then the best you can do
> to catch any error and handle it as an NSError becomes a two-liner:
>
> do {
> try something()
> } catch let error {
> let nsError = NSError(error)
> handle(nsError)
> }
>
> That's definitely uglier, but just to play devil's advocate, this does have
> the benefit of making it much clearer that the 'catch' is exhaustive. 'as'
> patterns are usually refutable, and it's a weird exception that 'error as
> NSError' is an exhaustive match (and we do have bugs where we get this wrong,
> especially inside closures when we haven't fully propagated contextual types
> yet).
Right, that’s what I expected. The problem here is that this is a super common
pattern. The solution to this is pretty straight-forward though: we should
just make the most commonly used members of NSError be a protocol extension on
ErrorProtocol (née ErrorType). This would eliminate the most common reasons
that people need this pattern. Do you know of any issues with this, or are we
merely a proposal away from making this happen?
-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
