> On Oct 24, 2017, at 11:36 AM, Tino <[email protected]> wrote: > > >>> If the biggest problem of flatMap is that people who don’t understand it >>> write code that isn’t optimal (but still does the right thing!), I don’t >>> think there is any change needed. I’m not even sure that that >>> wrapping/unwrapping is actually done, because it should be discoverable by >>> the compiler. >> It can be seen that the generated SIL is more complicated for a flatMap >> case, the microbenchmark also shows that it’s about 3x slower than the map. >> But even if that can be optimized away, don’t you find a String example from >> the proposal even a little convincing? > It’s unfortunate when a piece of code gets a different meaning — but as you > said: > It’s a misuse, and when you write code that is wrong, the results might be > wrong as well. And this is exactly that we’re trying to address. Not the impurity of the function, not the performance, but the potential to misuse. > > Maybe Scala chose better name for the concept, but the Swift definition is > consistent as it is now. collect does not say anything about the transformation (A => B) that happens along the way…
> So, if you remove the third overload, the second one imho should be renamed, > too. Honestly, I don’t see why. Can you elaborate? The second one is perfectly consistent, it does not mix two different functor instances in the same function.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
