<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="">On 18 Feb 2017, at 16:27, Karl Wagner <<a href="mailto:karl.swift@springsup.com" class="">karl.swift@springsup.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class="">- I wonder if we could try something more ambitious. Since the list of thrown errors is resilience-breaking for the function, it is only beneficial for versioned and @inlineable functions. They should not be able to add new errors (they can remove them though, since errors are intended to be switched over). I wonder if we couldn’t introduce a small pattern grammar for our structured comments (isolated from the rest of the language) - it would be optional, but if you do list your errors, the compiler would validate that you do it exhaustively. Some patterns I would like are:<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Courier" class="">// - throws: - MyError.{errorOne, errorThree, errorFive}: Something bad || considered exhaustive</font></div><div class=""><font face="Courier" class="">@inlineable public func canFail() throws {}</font></div><div class=""><br class=""></div><div class=""><font face="Courier" class="">// - throws: - OpeningError: Computer says nooooo... || considered exhaustive if OpeningError is versioned or @fixed</font></div><div class=""><div class=""><font face="Courier" class="">// - * || other errors, requires “catch-all” by external callers</font></div></div><div class=""><div class=""><font face="Courier" class="">@inlineable public func canFail2() throws {}</font></div></div><div class=""><font face="Courier" class=""><br class=""></font></div></blockquote><div class=""><div class="">If we want to get really clever, we can have the compiler automatically generate those error-lists for internal functions, so you would automatically get exhaustive error-handling within your own module.<br class=""><div class=""><br class=""></div></div></div><div class="">- Karl</div></div></div></blockquote></div><br class=""><div class="">Just to rephrase this a little bit.</div><div class=""><br class=""></div><div class="">- The list of thrown errors would not be part of the function’s signature. Instead, there is an ABI invariant that it throws an Error, and that it remains "switch-compatible". That’s a loose definition, but it covers things like throwing non-public Errors and later making them public while retaining ABI compatibility.</div><div class="">- It’s up to the library developer to maintain that invariant. They can remove errors, refine errors (e.g. “MyError” -> “MyError.{errorOne, errorThree}”), hide or reveal previously-hidden errors.</div><div class="">- If the errors are listed exhaustively, the compiler will generate an implicit catch-all to trap in case the library violates this invariant. This means they can become more specific while retaining ABI compatibility.</div><div class=""><br class=""></div><div class="">- We would put this information in the structured comments, because it can get long and complex and is always optional</div><div class="">- The compiler would ensure that their documentation is accurate, as it does any other part of the language.</div><div class=""><br class=""></div><div class="">- Karl</div></body></html>