[swift-evolution] [Proposal draft] NSError bridging

[Dmitri Gribenko]

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".

> 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.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/