[swift-evolution] Type-annotated throws

[Tino Heth]

> Am 02.09.2016 um 02:28 schrieb Douglas Gregor <dgregor at apple.com>:
> 
> Given that SE-0112 bridges *all NSError values in Objective-C* to Error, removing Error is a non-starter.

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 ;-).
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?

> Error is far from empty; it appears that way, but it contains default implementations
The protocols build on top of Error make absolutely sense to me, because they ensure features of conforming types.
Is there any reason to keep the methods of Error secret to Swift?
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).

> Plus, it’s a protocol rather than a base class, so conforming it doesn’t really constrain your design in any way.
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.
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"…)

btw:
The proposal concentrates on error-enums, but I can throw a plain Int or String as well.
Is this just due to limitations of the language that can't enforce that a conforming type is an enum?

Tino
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160902/fdfcfdfe/attachment.html>