I'm not sure what constraining the second generic placeholder to ErrorTypegives us. IIRC this has come up during discussions on other issues as well.

If there is stuff that only works on ErrorTypes we can always add that to a protocol extension like so:

extension ResultType where Error: ErrorType { }

Been thinking about this a lot lately, and wanted to open up a discussion about it.

Issues like #49 seem like a smell to me. Needing to maintain duplicate and parallel operator definitions in order to maintain compatibility with other libraries screams "shared dependency" to me. Ideally, I think Runes (or a similar lib) would define the operators, and then Result would define implementations for the types it exposes. That would allow the operators to have a single point of definition, and guarantee consistency for things like precedence.

Obviously, it's not that simple. Adding Runes as a dependency would mean needing to expose another framework that users would need to link against, even if they never use it. I think we're all in agreement that a lib like this should have as few dependencies as possible. Box makes sense, but adding in a dependency on Runes (especially after we've already pulled out the dependencies on Either and Prelude) doesn't.

Ideally, we'd be able to do some sort of optional dependency. It would be awesome to be able to say "Is Runes available? If so, here's this implementation of flatMap for result that you can use". (It would be more awesome to be able to define some sort of generic type for this. Like a higher kind of type. idk) But unfortunately Apple hasn't provided a way to do that.

As a temporary solution, what if the duplicate operators were moved into a second framework that included Runes as a dependency, leaving the basic Result framework pure?

PROS

• Users that never use >>- or any of the other operators would never see them, and would never need to worry about them
• Users that do use >>- and so forth wouldn't have to worry about conflicting operator definitions.
• Using a common dependency that implements these same operators for Optional and Array would theoretically increase exposure to these operators, driving education and adoption.

CONS

• This would require users that want >>- to import a module that is named something other than Result. ResultRunes or ResultOperators or whatever. That's fairly gross.
• When using Carthage to install Result, users would be left with 5(!) frameworks in their build directory. They would then have to know which ones to link to get what they want.

As a side note, this would be able to be implemented for CocoaPods by using subspecs. CP users would then only need to import Result no matter what, using a spec similar to this:

Pod::Spec.new do |s|
  s.name         = 'Result'
  s.version      = '0.4.3'
  s.summary      = 'Swift type modelling the success/failure of arbitrary operations'

  s.homepage     = 'https://github.com/antitypical/Result'
  s.license      = 'MIT'
  s.author       = { 'Rob Rix' => '[email protected]' }
  s.source       = { :git => 'https://github.com/antitypical/Result.git', :tag => s.version.to_s }
  s.source_files  = 'Result/Result.swift'
  s.requires_arc = true
  s.ios.deployment_target = '8.0'
  s.osx.deployment_target = '10.9'

  subspec 'Runes' do |subspec|
    subspec.source_files = 'Result/Runes.swift'
    subspec.dependency 'Runes', '>= 1.2.2'
  end
end

CP users would then be able to declare pod 'Result/Runes' and they would get both.

I don't think this PR should be used as the final implementation by the way, but meant it more as an example of how this could work in the service of conversation.

This is my attempt to help out with #51.

I'm not sure how great my example is... but I think it does demonstrate the core concepts well. And it was the first example I thought of.

I also tried to give a shoutout to map and flatMap, and a reference to Javi Soto's monads article (without mentioning the words Functor or Monad in the README). I'm not sure if this is a horrible idea. Seems like now that Swift 2.0 brings error handling the higher order functions are really what make results stand out as a better (IMO) solution to error handling. Since those features are one of the compelling reasons for Result I thought it might be appropriate to highlight them a little.

Anyway let me know what you think. Hopefully it's helpful.

This was changed in https://github.com/antitypical/Result/pull/141. But the current form does not looks correct since the ConvertibleType associated type is not used in any method signature.

This change ~~brings back the original definition~~ removes ConvertibleType from ErrorTypeConvertible and worked well for both Swift 2.2 on OS X and swift-DEVELOPMENT-SNAPSHOT-2016-03-24-a on Linux.

~~I'm using the latest development snapshot from January 18th. This compiles! 🎉~~

Last updated and tested with: Xcode 9.3 beta 2.

TODO:

• [x] Wait for Xcode 9.3
• [ ] Update Travis
• ~~Update build setting (it's still set to 4.0, because the toolchain didn't change the build setting)~~
• ~~Other improvements?~~

CAUTION: This patch is also not working for now in the same way as #56 . https://twitter.com/gfontenot/status/608774708159324161 #56 is great, but function version of materialize is easier to derive Result from failable closure.

let data = NSData()
let result = materialize {
    try NSJSONSerialization.JSONObjectWithData(data, options: [])
}

It seems >>- operator no longer works seamlessly with other operator-centric libraries e.g. Runes, Operadics, due to the new precedencegroup in Swift 3.

Formerly in Swift 2, "error: ambiguous operator declarations found for operator" did not occur iff associativity and precedence were totally equal, but this workaround no longer works in Swift 3, so I would like to suggest to either:

1. Remove custom operators in Result, or
2. Add de facto infix-operator library as a dependency (if there's any)

It will be nice if we can add Haskell's fmap and ap to support applicative style as https://github.com/thoughtbot/Argo 's Decoded<T> type can do.

Hi,

I just wanted to include Result in my project and am running across a few issues. It seems to me as if Alamofire (which is already a dependency) defines its own Result type throwing problems when trying to write functions that return results.

For example Xcode (7.0 beta 5) tells me that I can't write Result<MyDataType, MyErrorType> because Generic type 'Result' specialized with too many type parameters (got 2, but expected 1). I'm basing my usage of Result on this.

Both are linked as frameworks installed via Carthage in a Swift 2.0 project.

I'm guessing issues like this shouldn't actually be occurring, but I'm doing something wrong here. Any pointers would be great, thank you!

Changes are affected by:

• SE-0046 Establish consistent label behavior across all parameters including first labels
• SE-0055 Make unsafe pointer nullability explicit using Optional

I would like to do something in the lines of the following: typealias OperationResult = Result and just have any ErrorType as the error type. But as it is now I have to declare a concrete ErrorType Result<valuetype, NSError> Which means I can't use the feature of swift where every enum can just be an ErrorType. I have to use NSError only. Any workarounds?

The standard Swift coding convention is to have import statements on the top of the file.

Also, code completion results only show up after the import statement, so this change ensures that declarations from the Foundation module are correctly suggested in this file.

This code compiles without issue, where generatedEvents is of type [EKEvent] and eventStore is an EKEventStore:

for thisEvent in generatedEvents {
    let result = Result(try eventStore.save(thisEvent, span: .thisEvent, commit: false))
    print(result)
}

However, when I rewrite it as a map (to generate an array of Results):

let results = generatedEvents.map { thisEvent -> Result<(), AnyError> in
    let result = Result(try eventStore.save(thisEvent, span: .thisEvent, commit: false))
    print(result)
    return result
}

I receive the compiler error:

Call can throw, but it is not marked with 'try' and the error is not handled

However, looking at the Result initializer, it looks like the error is handled in a do/catch block.

I have a few situations where I need to convert a Result to a common type, and looking at other languages fold seems to exist.

Essentially, this:

public extension Result {

    /// Convert either a success or failure into type `U`
    public func fold<U>(success: (Value) throws -> U, failure: (Error) throws -> U) rethrows -> U {
        switch self {
        case .success(let value): return try success(value)
        case .failure(let error): return try failure(error)
        }
    }
}

Good idea / bad idea?

I'm pretty new to using Result, so perhaps this is possible by another concise means.

A variant of dematerialize that doesn't throw if the error type is NoError would be nice to have. I typically avoid try! throughout my code, and use SwiftLint to warn against its use. My options here are to use a magic comment to disable the SwiftLint rule, or do/catch - neither is particularly appealing. Thoughts?

When using Result in my project, I needed to use init(attempt:) in several places but I wanted to use my own wrapper for arbitrary Errors. The existing initializer only works with AnyError, so I've modified the code to allow using any Error which conforms to the ErrorInitializing protocol.