> On May 2, 2016, at 3:21 PM, Erica Sadun <er...@ericasadun.com> wrote: > > >> On May 2, 2016, at 4:15 PM, Chris Lattner <clatt...@apple.com >> <mailto:clatt...@apple.com>> wrote: >> >>> >>> On May 2, 2016, at 2:48 PM, Erica Sadun <er...@ericasadun.com >>> <mailto:er...@ericasadun.com>> wrote: >>> >>> >>>> On May 2, 2016, at 3:45 PM, Chris Lattner via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@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).
Hah, ok, thanks. I admit that I clicked the link and was disappointed that it wasn’t a firefly reference ;-) -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
