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).
0 voters
I’d like to see the yes and no votes broken down by whether you use skipmissing or not.
Ironically, I do not use it and voted “yes”.
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?
Instead of sm, what about here?
I think it might be a fair antonym of missing in this context?
sm is probably a short variable name that users won’t be able to use anymore? It might be better in this case something less short like skipm
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:
could_be_missing ?m replacement_value
could_be_nothing ? replacement_value
Or maybe with a double ??
@jules: use coalesce for this with missing and something for nothing.
I know but those are eager and longer. I always liked the ? syntax in Swift or Javascript, for unpacking things and handling nothings in a smooth way
how about mean(↷(x)) althought it looks better in the regular font ↷
j/k 
What does this mean? Would this be exported from Base, or do you have to using Missings?
It means it would be defined in Missings.jl and only made available if you did using Missings or any package that re-exports Missings.jl.
However, given the discussion above I think that the case is closed - it will not be added.
Could be good for MissingsAsFalse.jl.
Would need Julia’s syntax support first though.
There’s @something in Base for a lazy version now. Maybe @coalesce could be added too.
@coalesce has been added in 1.7 like @something.
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.
How about hinting the users at the possibility of aliases in the docs?
import Base: skipmissing as sm