Consistent bridging for NSErrors at the language boundary

[CharlesJS]

No description provided.

[lattner]

This is a great direction to investigate, and we definitely need to make progress here. However, the proposal acknowledges that we really need to resolve more fundamental questions about the bridging story. Also, the improvements suggested are largely additive, so we can do them at any time.

As such, it is best to defer discussion of this area until this Fall for consideration in a post Swift 3.0 release. Thank you for writing this up!

[CharlesJS]

Thanks for looking at my proposal. I would like to point out that although it is largely additive, it is not completely so; a small amount of code would be broken, including anything that explicitly constructs NSError objects and passes them to APIs that expect ErrorProtocols. Also, all of the explicit casts/conversions of Swift errors to NSError would need to be removed, as they would be unnecessary in the new regime. I do believe that the benefits would greatly outweigh the costs here, so if source compatibility is a major concern post-3.0, it may be better to look at this (and the associated bridging issues) sooner rather than later. If small code-breaking changes are still kosher post-3.0, however, then this is no problem, and I will resubmit the proposal in the fall, adjusted to fit whatever decisions are made regarding the bridging behavior. I assume the time to do that would be shortly after 3.0 is released?

Thanks,
Charles

[lattner]

I understand your concern, but the reality is that this is a very large design effort. I'm pretty confident that we can roll out the benefit of this with either no source breakage, or opt-in breakage that can be staged over time. As plans for releases beyond Swift 3 are developed, we'll come up with a specific strategy. This isn't the only proposal in this situation.