The object we were using flatMap on used to be optional. The fix was to use
a map instead since it was no longer needed to be flatMapped. I agree that
this would be a mis-use of flatMap but the inference behaviour here is
still unexpected.
If the compiler doesn't support multi-statement closure ty
Compare https://bugs.swift.org/browse/SR-1570 : Swift can infer the return
type from single-statement closures, but not from multi-statement closures.
Therefore in
let result = strArr.flatMap { x in
return x
}
the closure type is inferred as (String)-> String, and therefore th
On 21.10.17 02:50, Santiago Gil via swift-users wrote:
I just ran into a bug after a Swift 4 migration where we expected
[String] and got [Character] from a flatMap since flatMap will flatten
the String since it's now a collection. While I understand why
flatMap behaves this way now that strin
Hi Swift users,
I just ran into a bug after a Swift 4 migration where we expected [String]
and got [Character] from a flatMap since flatMap will flatten the String
since it's now a collection. While I understand why flatMap behaves this
way now that string are collections, in testing this I found
