-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
make coalesce handle only missing; add something
#27258
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
nalimilan
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Looks reasonable to me.
| julia> coalesce(1, missing) | ||
| 1 | ||
| julia> coalesce(nothing, 1) # returns `nothing` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably better remove this example, there's no reason to think that nothing is treated differently from any other value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the point of the example is to demonstrate that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I understand that, but my point is that nobody would have imagined coalesce would consider nothing as a missing value, except for the fact that it was the previous behavior. And since most people won't know that history...
Anyway, not a big deal.
| """ | ||
| notnothing(x::Any) = x | ||
| notnothing(::Nothing) = throw(ArgumentError("nothing passed to notnothing")) | ||
| something() = throw(ArgumentError("No value arguments present")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same remark as for the zero-argument coalesce below.
|
|
||
| """ | ||
| coalesce(x, y...) | ||
| notnothing(x) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As you noted, I think we can just remove notnothing and use something instead. I don't think we use it in situations where accidentally unwrapping Some is possible. On the contrary, I only used notnothing in places where Nullable previously required explicit unwrapping, which ensured null values were caught early. Anyway it's internal.
doc/src/base/base.md
Outdated
| Base.coalesce | ||
| Base.ismissing | ||
| Base.skipmissing | ||
| Base.something |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be listed with nothing and Some instead, it's totally unrelated to missing.
| """ | ||
| function coalesce end | ||
|
|
||
| coalesce() = missing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd find it more natural to define coalesce(x::Missing) = throw(...). There's no reason to define a function with zero arguments AFAICT. Same remark for something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't ancient Rome; we understand zero now 😁
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I 100% agree with Jeff here. Zero things is missing the same way the sum of no things is zero and the product of no things is one. If we knew the type in those cases, we would absolutely define the empty sums and products to do that; in this case we do know the type and can return missing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, why not, though I'm not sure in what cases it could be useful. OTOH I don't think it makes sense for EDIT: Actually now I see it's somewhat similar, even though it's not that useful since an error is thrown anyway.something (since an error is thrown), but let's discuss it in the other thread above.
|
I also realized it would be nice to have a deprecation for |
6caeb71 to
60d0141
Compare
|
I've rebased and added a commit moving the docs. I'm not sure how to correctly add a deprecation, given that the behavior has changed in an incompatible way. We could just print a warning pointing to |
|
Why did freebsd not happen here? |
|
This PR was all green but the conflicts are out of merging the statistics-stdlib PR. I think we should try and merge it today, if the PR is otherwise ready. |
60d0141 to
143c7f1
Compare
|
Rebased on master. Might as well let CI have another go at it. @iblis17 FreeBSD doesn't seem to be picking this up. |
|
@ViralBShah I think it built already. just queuing before. |
|
Thanks @iblis17. So all green! Is |
|
I think I might prefer |
|
I believe F# calls this |
|
Another data point: |
|
Scala also has |
|
Yeah. The terminology "null-coalescing operator" is more standard, but even though |
|
How about we go with |
|
I like |
|
I'm not a big fan of |
|
I suggest merging this as is for now, in order to not block the alpha, and changing the name to something else should we want to before the release candidate. |
|
Personally, I'm fine with |
|
I am going to merge this now. We still have the rest of the day or maybe even tomorrow to pick a different name. |
|
I like |
|
After some initial skepticism, I've come to like |
Totally think that is a better choice. |
|
That would dovetail with a whole other suite of
The collection of them is fairly compelling since they're all nothingesque rather than missingesque. |
|
That actually suggests an unexpected option that doesn't involve new syntax: |
|
I assume we would want I also have to admit this makes me entertain the heretical thought that we should consider combining |
|
Yes, it would be lazy, of course, I should have indicated that. Having both |
|
True. The |
|
It would totally make sense to use all the EDIT: We used |
|
My impression is that the main problem with |
|
But then it's weird when not all arguments are |
|
|
This is a possible approach to fixing #26927. Overall I like it. The name
somethingis ok, but didn't feel perfect. Basically all uses ofcoalescein Base were for providing default values forfindormatchfunctions, andsomething(findnext(...), 0)doesn't read quite right. I also notice that it's very similar tonotnothing, and the functions could perhaps be combined (one way or the other).