[swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

[David Hart]

I got the reference, made me laugh :)

> On 03 May 2016, at 00:21, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On May 2, 2016, at 4:15 PM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>> 
>>> 
>>> On May 2, 2016, at 2:48 PM, Erica Sadun <erica at ericasadun.com <mailto:erica at ericasadun.com>> wrote:
>>> 
>>> 
>>>> On May 2, 2016, at 3:45 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 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.
>>> 
>>> Grant me the serenity to accept the `NSError` I cannot change and the courage to change the bridging conversions I should. Grant me the wisdom to know the difference between a partial solution that offers a cleaner more predictable interface set now and a full solution that cannot be achieved in a reasonable timeframe.
>> 
>> I’m not sure what you’re saying.
>> 
>> -Chris
> 
> It's a message of support, riffing on the famous Serenity Prayer (https://en.wikipedia.org/wiki/Serenity_Prayer <https://en.wikipedia.org/wiki/Serenity_Prayer>), agreeing with you and saying that partial implementation of a good idea (limiting bridging conversions between value types and a subset of Cocoa classes) is to be preferred to a full implementation of an idea that requires extraordinary effort for one special case (NSError).
> 
> -- E
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160503/7e82f10d/attachment.html>