Recently I recieved this closure reason on a bug report about the false overload of flatMap
This issue behaves as intended based on the following:
Yes, we are aware that this overload of flatMap could be viewed as unconventional. Nevertheless, it is useful and fits the overload set in general, if you view Optional as a sequence of zero or one T. It resembles this overload, where the closure returns an arbitrary sequence:
extension SequenceType {
public func flatMap<S : SequenceType>(
transform: (Generator.Element) -> S
) -> [S.Generator.Element]
}
The type checker ensures that there is no ambiguity between the two overloads, and we don't see a reason to give one of the overloads a different name (and force users to learn it, and differentiate between the two), since conceptually the operation is the same.
If Swift wishes to regard Optional (rather strangely) as a sequence of 0 or 1 value, I say we let them have their wish and add a SequenceType extension if they won't. As an added bonus, it'll make the SequenceType overloads in Aquifer a bit more general.
Recently I recieved this closure reason on a bug report about the false overload of flatMap
If Swift wishes to regard Optional (rather strangely) as a sequence of 0 or 1 value, I say we let them have their wish and add a SequenceType extension if they won't. As an added bonus, it'll make the SequenceType overloads in Aquifer a bit more general.