[swift-evolution] [Proposal draft] NSError bridging

[Matthew Johnson]

Sent from my iPad

> On Jun 30, 2016, at 12:56 AM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jun 29, 2016, at 10:05 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>> 
>> On Wed, Jun 29, 2016 at 4:13 AM, Charles Srstka
>> <cocoadev at charlessoft.com> wrote:
>>> On Jun 29, 2016, at 2:50 AM, Dmitri Gribenko via swift-evolution
>>> <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>> I'm not sure I really want '.url' and '.stringEncoding' on every
>>> Error.  'var underlying' is universally useful, but providing it
>>> requires a implementing conformance to CustomNSError, which has to
>>> vend a weakly-typed dictionary.  Is this really the API we want to
>>> expose?
>>> 
>>> 
>>> We need to expose the dictionary in order to provide full compatibility with
>>> NSError.
>> 
>> The full compatibility argument is universal, and it can be applied to
>> anything.  Not always the answer is "dump the compatibility APIs onto
>> the Swift type”.
> 
> Yes, that’s a reasonable point. These APIs are available by bouncing through NSError and (at worst) looking up a known key in its userInfo dictionary. I only truly care about localizedDescription being available on Error(Protocol), because that’s universal and useful. The others… I think I’ll go put them on (NS)CocoaError, which covers the Cocoa error domain and is where one might reasonably expect these keys to show up. It’s fairly easy for other, specific error types to do the same if they need them. If we truly need some of these on all error types, we can add that at a later time.
> 
> I’ll revise the proposal shortly.
> 
>> 
>>> Also, the underlying error has to be stored somewhere, which
>>> effectively prevents implementers of CustomNSError from being enums.
>>> 
>>> 
>>> Not at all. Your enum can implement a dynamic errorUserInfo property that
>>> will populate the dictionary with the appropriate values. If you need to
>>> actually store something, that can be done with enum cases as well.
>> 
>> You would need to store the underlying error in every enum case, which
>> creates boilerplate, and you'd lose the raw representable conformance.
> 
> 
> If it’s important for the error type to store the underlying error, you can use a struct or add the payload to every enum case. Maybe some future feature will make the latter option easier (I feel like we saw a pitch about that before).

There was a pitch along these lines.  IIRC it was something like stored properties for enums where you could declare the property once and it would be added to the payload of all cases as well as available directly as a property.  I thought it sounded useful - underlying error is an example of a good use case.

I'm pretty sure there was pretty strong negative feedback along the lines that is blurs the distinction between struct and enum too much and I think that feedback came from someone on the core team.  I don't recall the exact details though.

> 
> 	- Doug
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution