BrightFutures 2.0

[Thomvis]

Open questions:

• Should Future<T, E>.succeeded(_: T) return a Future<T, NoError> or a Future<T, E>?
• Do we need an Either (or EitherError)?

Todo:

• Update README

[Thomvis]

I've finished the first stab at getting rid of NSError in the framework and it has turned out quite nice, I think. One thing that I'm not so happy about yet is that I need EitherError where two types of errors could be returned, e.g.

BrightFutures/BrightFutures/Future.swift

Line 485 in 9335a5c

public func filter(p: (T -> Bool)) -> Future<T, EitherError<E, BrightFuturesError>> {

. It might not be a very big deal and I will think about it more. Feedback is welcome!

[robrix]

You might consider adding an External case to this enum which carries an ErrorType:

case External(ErrorType)

public var nsError: NSError {
    switch self {
    …
    case let .External(e):
        return e
    }
}

This would seem to obviate the need for EitherError, which would yield a simpler API.