-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
make coalesce
handle only missing
; add something
#27258
Conversation
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.
@@ -33,47 +33,39 @@ function show(io::IO, x::Some) | |||
end | |||
|
|||
""" | |||
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
@@ -228,6 +228,7 @@ Base.missing | |||
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
something
is ok, but didn't feel perfect. Basically all uses ofcoalesce
in Base were for providing default values forfind
ormatch
functions, 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).