Type alias result without committing to an error type about result HOT 10 CLOSED

Possibly Result<ErrorType, …>?

from result.

You get an "Expected type" error.
I am not sure how important it is to decide the error type on declaration instead of just having an failure(ErrorType).

from result.

Got my parameters the wrong way around. If your operations produce strings, then:

typealias OperationResult = Result<String, ErrorType>

would work, except:

boom.swift:16:29: error: using 'ErrorType' as a concrete type conforming to protocol 'ErrorType' is not supported
typealias OperationResult = Result<String, ErrorType>
                            ^

Maybe we should stop constraining Result’s Error type parameter to ErrorType?

from result.

Hmmm, in my own private implementation I had something in the lines of:

Result<T>
case Success<T>
case Error <ErrorType>

So this one essentially does the same but you don't have to commit to a specific concrete ErrorType. I think it's more swift-y to say put whatever you want as long as it conforms to ErrorType.

Then you would declare an Result<type> and it's obvious in my opinion that the result also has an error. You don't initialize an optional saying Optional<type,nil> cause its obvious

from result.

Maybe we should stop constraining Result’s Error type parameter to ErrorType?

This would break all of the throws methods defined in Result.

So this one essentially does the same but you don't have to commit to a specific concrete ErrorType. I think it's more swift-y to say put whatever you want as long as it conforms to ErrorType.

This defeats one of the main benefits of Result which is compile-time error checking

from result.

This would break all of the throws methods defined in Result.

Ah, of course.

So this one essentially does the same but you don't have to commit to a specific concrete ErrorType. I think it's more swift-y to say put whatever you want as long as it conforms to ErrorType.

This defeats one of the main benefits of Result which is compile-time error checking

Agreed. I want Swift to declare concrete error types, not to elide them from Result.

from result.

This defeats one of the main benefits of Result which is compile-time error checking

What advantages do you get from have the type Result<type, NSError> as oppose to Result<type, ErrorType> ?

Agreed. I want Swift to declare concrete error types, not to elide them from Result.

Swift's design already made the choice of not declaring concrete error type in the throws and in fact when you use throws in the Result you lose that information. Otherwise you would write foo() throws CBError or something in the sorts. In all honesty the fact that you have to choose a concrete type at definition is probably a swift error. There is no reason you shouldn't be able to repass ErrorType as a type for your error.

from result.

@yoavschwartz you could create your own enum and then make it conform to ResultType. That will give you most functionality of Result (e.g. map, flatMap) just by implementing a few basic methods on your own type. It might not be a complete solution (we could make it more compelling by moving more functionality from Result to ResultType), but perhaps an interesting one to try out.

from result.

@Thomvis It's actually what I am already doing ;) I just thought the Result type itself makes more sense when defined by one type and wanted to discuss the pro's and con's like we did here. I am satisfied that there are compelling arguments for both types and you have done great work with the code you wrote. It comes down to design choices. I tried to come up with a way to support both types but you can't overload an Enum.

from result.

With that, I’m going to close this out, as there doesn’t seem to be any action to be taken. Thanks for an interesting discussion, all!

from result.