<html><head></head><body dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><blockquote type="cite">On Jun 29, 2016, at 10:05 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:<br><br>On Wed, Jun 29, 2016 at 4:13 AM, Charles Srstka<br><cocoadev@charlessoft.com> wrote:<br><blockquote type="cite">On Jun 29, 2016, at 2:50 AM, Dmitri Gribenko via swift-evolution<br><swift-evolution@swift.org> wrote:<br><br><br>I'm not sure I really want '.url' and '.stringEncoding' on every<br>Error. 'var underlying' is universally useful, but providing it<br>requires a implementing conformance to CustomNSError, which has to<br>vend a weakly-typed dictionary. Is this really the API we want to<br>expose?<br><br><br>We need to expose the dictionary in order to provide full compatibility with<br>NSError.<br></blockquote><br>The full compatibility argument is universal, and it can be applied to<br>anything. Not always the answer is "dump the compatibility APIs onto<br>the Swift type”.<br></blockquote><br>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.<br><br>I’ll revise the proposal shortly.<br><br><blockquote type="cite"><br><blockquote type="cite">Also, the underlying error has to be stored somewhere, which<br>effectively prevents implementers of CustomNSError from being enums.<br><br><br>Not at all. Your enum can implement a dynamic errorUserInfo property that<br>will populate the dictionary with the appropriate values. If you need to<br>actually store something, that can be done with enum cases as well.<br></blockquote><br>You would need to store the underlying error in every enum case, which<br>creates boilerplate, and you'd lose the raw representable conformance.<br></blockquote><br><br>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).<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug<br><br></body></html>