<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 02.09.2016 um 02:28 schrieb Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Given that SE-0112 bridges *all NSError values in Objective-C* to Error, removing Error is a non-starter.</div></div></blockquote></div><br class=""><div class="">I see my wording was to simple — instead of just "removing ErrorType", I should have written "… removing the restriction that thrown types have to conform to Error" (I just noticed "ErrorType" is already scheduled for removal ;-).</div><div class="">Interoperability is an important aspect, but imho it shouldn't be enforced — in the future, there might be many Swift developers that don't care for Objective-C anymore; or is there anything special about Error besides the "magic" bridging to NSError?</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Error is far from empty; it appears that way, but it contains default implementations</blockquote><div class="">The protocols build on top of Error make absolutely sense to me, because they ensure features of conforming types.</div></div><div class="">Is there any reason to keep the methods of Error secret to Swift?</div><div class="">Imho it would feel much less arcane if you could ask an error for its NSError-properties (in a playground, for example, I guess I currently have to bridge to NSError manually to see its domain & code).</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Plus, it’s a protocol rather than a base class, so conforming it doesn’t really constrain your design in any way.</blockquote>I never worried for constrained design; it's just that conforming to (empty) Error afaics has no benefit for pure Swift code with annotated throws.</div><div class="">Especially in the common case of error-enums, I realize the aspect of using ": Error" for documentation — but depending on the name of the type, this is redundant ("enum NetworkError: Error"…)</div><div class=""><br class=""></div><div class="">btw:</div><div class="">The proposal concentrates on error-enums, but I can throw a plain Int or String as well.</div><div class="">Is this just due to limitations of the language that can't enforce that a conforming type is an enum?</div><div class=""><br class=""></div><div class="">Tino</div></body></html>