The following section seems wrong.
“You’ve seen how Combine includes operators such as map that correspond and work similarly to higher-order functions found in the Swift standard library. And you’ve learned about the flatMap operator, which doesn’t work at all like its renamed counterpart.”
Flapmap respects the mathematical properties / concepts of all its counterparts. For example, flatmap on optional makes certain you get an Optional value and not Optional<Optional>, what you would get by using map. Exemple .optional(“2”).flatmap(Int.init). The same way flatmap on Result, let you have a Result and not Result<Result> when you would return a result in a map. Flatmap solves the nesting problem in general of mapping when the transformation gives the base type. flatmap here does the same so we do not nest publisher!
Hi @sproy and welcome to the RW community!
Thanks for bringing this up. Although
flatMap in Combine does not as closely resemble the behavior of other counterparts between Combine and the Swift standard library, I see what you mean about there being a commonality regarding the mathematical aspects between the two. So I’ll remove mentioning that Combine’s
flatMap doesn’t work at all like its counterpart.
Just to point out though, the publisher returned by
flatMap does not — and often will not — be of the same type as the upstream publishers it receives.
It is fun to read the beta version of the book and participate
Fun fact, when you define flapmap on a type and if you prove that it respects some basic property, you have found the only possible definition of flatmap, there can not be another one, it is unique! (I did my studies in mathematics before switching to computer after my master :)) here is a fun article https://medium.com/beingprofessional/understanding-functor-and-monad-with-a-bag-of-peanuts-8fa702b3f69e.
Also, if you have a new beta of the book before the final versionI will would love to read it and provide feedback. Great job on the 5 first chapter