Certainly map in the name indicates the application of a transform closure, and the name for this operation, if it doesn't take a closure, likely ought to be different.
That's a very good point that I did not consider. But e.g. compact() (or something similar) still does not exist, or does it?
It seems like there must have been a discussion before or maybe even a reason why it shouldn't exist or why it's not necessary (e.g. because there is a better way).
IMO a slightly more elegant solution is to have a func id<T>(_ v: T) -> T { v } in the standard library which enable us to write blah.compactMap(id). This id/identity function can further compose with operators in ReactiveX libraries, for example.
You’re proposing a method called compactMap() that doesn’t actually map anything, merely filters out nils.
If compactMap had never existed, being composible instead from map and some sansNils, then you would just use sansNils in isolation for this purpose.
The existence of compactMap is a bit of a mistake, I think - one people largely accept because it’s still fairly practical. But making it worse would be, well, even worse.
Sidenote: I don’t like the use of the term compact in any of this, because it’s way too ambiguous - it doesn’t say to me “removes nil“ specifically. Why doesn’t it mean to reallocate the underlying memory as one contiguous block? Or switch the internal representation from a linked list to an array? Or resize the backing memory to exactly the size of the current contents? Or apply bzip2 compression? Or reduce the type of the collection’s contents to the smallest type that still holds all the values (e.g. Int -> Int8)? Or remove duplicates? All of those are forms of compaction. It seems it only exists because somehow it got established as convention - some kind of chicken-and-egg paradox.
But in absense of parameterised generics (something like extension<T> Sequence where Element == T? { ... }), I think overeager autocompletion might still be the issue preventing the adoption of this somewhat hacky implementation in the stdlib; we don't want to suggest xs.compact() when xs is not a sequence of optionals.
IIRC we don't have compact because we don't have higher-kinded-types in Swift yet. If you use compact on a Set you want that the result remains a Set and is not transformed to an Array.
The best workaround right now is as already mentioned above compactMap(\.self), but since the proposal that enabled that feature didn't land yet you may need to create a custom operator for the time being and write compactMap(^\.self).