flatMap

[JaapWijnen]

Any specific reason methods like flatMap and sequence (from the pointfree.co episodes)aren't included in the package?

[stephencelis]

Hi @JaapWijnen! We have a discussion about this in our episodes on flatMap, particularly part 5: https://www.pointfree.co/episodes/ep46-the-many-faces-of-flat-map-part-5

In short, types with flatMap can automatically derive map and zip:

func map<NewValue>(_ transform: (Value) -> NewValue) -> MyType<NewValue> {
  self.flatMap { /* return new MyType by transforming self.value and bundling it up */ }
}

func zip<A, B>(_ a: MyType<A>, _ b: MyType<B>) -> MyType<(A, B)> {
  a.flatMap { a in b.flatMap { b in /* return new MyType by bundling up 'a' and 'b' */ } }
}

However, this zip derived for Validated is not the same as the zip we have defined:

• Zip as we've defined accumulates errors
• Zip derived from flatMap will bail out on the first error

Because of this flatMap can lead to missing out on the very validation information the type is designed for 😅 Luckily, we have the Result type for this kind of thing.

I'm going to convert this to a discussion, but maybe we should mention the absence of flatMap in the README. Thanks for the discussion!

[JaapWijnen]

Ah ok! Thanks @stephencelis, I was skimming over to find it but missed that part! Still wouldn't flatMap be useful when not used as an implementation for map and zip? For example in functions like :

let validation = Validated { try file.read() }
    .flatMap { data in 
        if let error = functionReturnsOptionalError() {
            return .invalid(error)
        }
        let processedData = data.process()
        return .valid(processedData)
    }

I'm was trying to change a lib that was mostly using throwing functions to use Result but then quickly moved to Validated. But it's not super easy to port, and feels like I'm missing some helpers sometimes.
For example what would be a good way to move away from throwing for a function with the following signature:
doThing(inout data: String) throws
I thought about returning an optional error? And then wrapping that in a validation? Or just returning a Validated<Void, Error> Not sure what the best approach is.

Also, Any reason for things like sequence: [Validated<Value, Error>] -> Validated<[Value], Error> not making the cut?
Also: init(catching f: () throws -> Value) has been very useful

[JaapWijnen]

@stephencelis Was still thinking about this. Even with your explanation (and rewatching the episode you mentioned) I don't fully understand why the new zip (not derived from flatmap) wouldn't be able to live side by side with flatMap. Would you mind elaborating a bit more? Allowing flatMap as API doesn't force us to use a zip function based on flatMap does it?

[stephencelis]

Yeah there definitely could be some improvements to the Validated API. We have plans to revisit it in the future and will consider some kind of operation like this, though we'll probably give it a different name so as not to break the intuition of how flatMap and zip can differ. There are a ton of things we can polish in addition, like adding functions to transform Result to Validated and back again.

[JaapWijnen]

Yes that last bit was also exactly what I was looking for :)! Would love to help out if that's of any use!