> Am 02.09.2016 um 02:28 schrieb Douglas Gregor <[email protected]>:
>
> 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_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
