Type-annotated throws

Right, this has come up many times before. I’m personally in favor of it, I believe that John McCall has concerns about it. In either case, it is out of scope for stage 1, because we need resilience to be figured out before we can consider this feature.

-Chris

···

On Aug 26, 2016, at 10:22 AM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:

Forwarding to more people:
This idea has already been discussed, and Chris Lattner specifically mentioned that this proposal will be suitable for Swift 4 Phase 2. But right now we shouldn't create a proposal for this.

mhh… true, but I hope that is not your only motivation to support this change ;-) (I definitely don't want to see a flood of breaking changes that are only introduced to speed up the integration of proposals).

···

Am 29.08.2016 um 14:21 schrieb Anton Zhilin <antonyzhilin@gmail.com>:

+1 for removing Error protocol. Then it's a breaking change, and this edition of the proposal can be reviewed for Stage 1.

Given that SE-0112 bridges *all NSError values in Objective-C* to Error, removing Error is a non-starter.

  - Doug

···

On Aug 29, 2016, at 12:14 PM, Charles Srstka via swift-evolution <swift-evolution@swift.org> wrote:

On Aug 29, 2016, at 4:18 AM, Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I'm quite skeptical here (Java has already been mentioned…), but if it's done, I'd vote for removing ErrorType:
This empty protocol always felt a little bit odd to me, and when each function has information about what errors to expect, imho there is absolutely no benefit associated with conformance.
Even now, it's not that much — or does anyone actually consult a list of conforming types for error handling?

Tino

Error is far from empty; it appears that way, but it contains default implementations to make bridging to and from Cocoa NSError objects much more convenient, especially since SE-0112. Plus, it’s a protocol rather than a base class, so conforming it doesn’t really constrain your design in any way.

-1 on removing Error.

Forwarding to more people:
This idea has already been discussed, and Chris Lattner specifically
mentioned that this proposal will be suitable for Swift 4 Phase
2. But right now we shouldn't create a proposal for this.

Right, this has come up many times before. I’m personally in favor of
it, I believe that John McCall

...and me, and IIRC Doug G...

···

on Sat Aug 27 2016, Chris Lattner <swift-evolution@swift.org> wrote:

On Aug 26, 2016, at 10:22 AM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:

has concerns about it. In either case,
it is out of scope for stage 1, because we need resilience to be
figured out before we can consider this feature.

--
-Dave

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

···

Am 02.09.2016 um 02:28 schrieb Douglas Gregor <dgregor@apple.com>: