I'd give it an not-particularly-passionate yes. The ergonomics are nice; the need is not dire.
I'm not wild about the name filter for the first. I see the parallels between optionals and sequences, but it's a limited parallel. The name is just as likely to miss type errors as it is to provide useful understanding.
See previous discussion of why Optional doesn't conform to Sequence or Collection, and the downsides of reusing names between the two:
What is your evaluation of the proposal?
Strong approve.
I would happily also accept name variants such as mapFilter — but I’m heartily in favor of _something_ that distinguishes _by name_ flattening sequences vs. filtering nils.
Is the problem being addressed significant enough to warrant a change to Swift?
The existing overloading of “flatMap” is not just confusing; it actively defeats some of the usefulness of Swift’s type checking. The proposal’s examples demonstrate this with the st…
The problem in the Doodads example is that the name flatMap is used to identify two distinct intents: concatenating arrays and filtering nils. One can argue that those two operations are, in some lofty abstract sense, if you squint, two instances of some more general pattern — but I don’t think it’s fair to say that they represent the same intent. These separate intents deserve separate names.
They absolutely represent the same intent if you think of an optional as a collection of zero or o…
The problem in the Doodads example is that the name flatMap is used to identify two distinct intents: concatenating arrays and filtering nils. One can argue that those two operations are, in some lofty abstract sense, if you squint, two instances of some more general pattern — but I don’t think it’s fair to say that they represent the same intent. These separate intents deserve separate names.
They absolutely represent the same intent if you think of an optional as a collection of zero or …
[Edit: wow, those intra-forum links are HUGE.]