> On 18 Feb 2017, at 16:27, Karl Wagner <karl.sw...@springsup.com> wrote:
>
> - 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:
>
> // - throws: - MyError.{errorOne, errorThree, errorFive}: Something bad
> || considered exhaustive
> @inlineable public func canFail() throws {}
>
> // - throws: - OpeningError: Computer says nooooo... || considered
> exhaustive if OpeningError is versioned or @fixed
> // - * || other errors,
> requires “catch-all” by external callers
> @inlineable public func canFail2() throws {}
>
> 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.
>
> - Karl
Just to rephrase this a little bit.
- 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.
- 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.
- 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.
- We would put this information in the structured comments, because it can get
long and complex and is always optional
- The compiler would ensure that their documentation is accurate, as it does
any other part of the language.
- Karl_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
