> On May 2, 2016, at 3:50 PM, Chris Lattner <[email protected]> wrote:
>
>
>> On May 2, 2016, at 3:43 PM, Joe Groff <[email protected]> wrote:
>>
>>
>>> On May 2, 2016, at 2:45 PM, Chris Lattner <[email protected]> wrote:
>>>
>>> On Apr 29, 2016, at 3:00 PM, Joe Groff via swift-evolution
>>> <[email protected]> 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?
I can't think of any problems that would block us from doing that today. It'd
be pretty easy to write an ErrorProtocol extension that just forwards NSError's
interface via bridging, and I bet that'd cover most use cases for 'as NSError':
extension ErrorProtocol {
var domain: String { return NSError(self).domain }
var code: Int { return NSError(self).code }
var userInfo: [String: AnyObject] { return NSError(self).userInfo }
/* etc. */
}
-Joe
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
