Sorry Charles, I should’ve been more specific. This isn’t about some
other type named Error being usable, but about our doubly generic Result and
other types being usable with Error as the generic error type. If we have
Result defined as:
public enum Result<Value, ErrorType: Error> {
case success(Value)
case failure(ErrorType)
}
then attempting to create the type Result<Whatever, Error> results in the error
message I posted. For methods that previously returned Result<Whatever,
NSError>, where the NSError is either a system error or an Alamofire one, this
is something of a problem. Of course, removing the generic error type fixes
this but may have an undesirable usability impact, as making Result double
generic was the primary reason behind the quick upgrade between Alamofire 2 and
3. I think it’s less of a problem now, as having to enumerate all of the
different expected error types is how user’s are supposed to interact with
Error in the first place, but at the time it wasn’t desirable to try and force
everything through ErrorProtocol for that reason. Perhaps this is a good
compromise, where instead of returning all NSErrors from the framework and
allowing consumers to add their own to the mix we’ll just create our own
AFError type (whether enum or struct) and then anything coming back will have
to be checked for that type in addition to the system types. From my testing it
looks like users could still wrap everything coming in by capturing the
underlying Error.
Jon
> On Aug 14, 2016, at 3:03 AM, Charles Srstka <cocoa...@charlessoft.com> wrote:
>
>> On Aug 14, 2016, at 1:18 AM, Jon Shier via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> An immediate problem I’m seeing is the error: using 'Error' as a
>> concrete type conforming to protocol 'Error' is not supported, which means
>> we can’t use Error in our Result or Response types, as both the value and
>> error types are generic there. I’m guessing we’ll have to either remove the
>> generic error type, which would greatly impact consumer’s ability to use our
>> APIs with their own custom errors, or wrap all errors in our own error type,
>> which is terrible for a few reasons. Or just keep using NSError I guess. Any
>> clever solutions here?
>
> Works fine when I try it:
>
> import Foundation
>
> struct MyThing {
> enum Error: Swift.Error, LocalizedError {
> case doesNotCompute
> case imSorryDave
> case mustSterilize
>
> var failureReason: String? {
> switch self {
> case .doesNotCompute:
> return "Does Not Compute! Does Not Compute! Does Not Compute!"
> case .imSorryDave:
> return "I'm sorry Dave, I'm afraid I can't do that."
> case .mustSterilize:
> return "Error! Must Sterilize! Must
> Steeerrrrilllliiiiiiizzzzzzeeeeeee"
> }
> }
> }
>
> func trySomething() throws {
> throw Error.doesNotCompute
> }
> }
>
> let thing = MyThing()
>
> do {
> try thing.trySomething()
> } catch {
> print(error.localizedDescription)
> }
>
> Outputs:
>
> The operation couldn’t be completed. Does Not Compute! Does Not Compute! Does
> Not Compute!
>
> Charles
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
