>> 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.
Maybe Scala chose better name for the concept, but the Swift definition is
consistent as it is now.
So, if you remove the third overload, the second one imho should be renamed,
too.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
