Do you think const sm = skipmissing should be added and exported from Missings.jl?
The point is that then mean(skipmissing(x)) would be abbreviated to mean(sm(x)). Given skipmissing is often needed I would propose to consider adding such a definition. Of course it is easy to add const sm = skipmissing in your code, but I think that it is important to have such definition as a standard if we agreed to it (then it would be consistently known and recognized by everyone).
Although I like the thinking, I personally find it obfuscatory to what the sm function would actually do as opposed to skipmissing being explicit and for that reason, I vote no.
Especially as a frequent user of skipmissing in a lot of data analysis.
Although, this could be a vestigial paradigm from my days working in Python regularly.
The notion of having abbreviations is nice and ergonomic however.
Wonder if there is something there that could go into a separate package?
Thank you all for the feedback. It is really valuable. Assuming, in relation to what @jlapeyre commented, that many skipmissing users voted it seems that the initial design decision (to be explicit with naming) is something people like (this is exactly what we wanted to confirm).
As an additional note, related to what @rafael.guerra has written, skipmissing in practice is written as skipm<tab> taking advantage of autocompletion (and it looks like users find this acceptable).
I’ve been thinking about using the question mark for missing related functionality. Not sure if skipmissing would work with that but at least replacing missings. Because nothing and missing serve similar purposes maybe one would need two syntax variants:
Hm yes, it’s good to have that macro. But somehow it still feels like Missing and Nothing in Julia are not really given the special treatment they deserve. There is basically no syntax sugar afforded to working with them, even though handling missing or nothing is such a commonplace task. Maybe the problem is that we have both but standard syntax sugar like ? has only one variant.
Things I’d like to see are option like types such as String?, unpacking syntax like container?.field or unpacking such as possible ?? default.