Add generic isnull and unsafe_get methods#18484
Conversation
|
I'm not sure how Base wants to handle things, but I would say that the removal of a dead branch in code like the following is what we require: function loop(x::Vector)
s = 0.0
for x_i in x
if !isnull(x_i)
s += x_i
end
end
return s
end
code_llvm(loop, (Vector{Float64}, )) |
|
That makes sense. I will leave that assessment to somebody who can read LLVM code. This PR also seems an appropriate place to introduce an analogous method for the unwrap(x::Nullable) = x.value
unwrap(x) = xas in John's jplyr notes. |
|
I think we definitely want something like |
|
Regarding |
|
In other contexts (e.g. C++ futures), |
|
LLVM can already eliminate the branch, but inference cannot. See Dead branch elimination after inlining #17880 |
|
Should this wait for or become part of #18510 ? |
The two changes can be made independently, so we can merge any of them we want. |
|
@davidagold Should probably add a test for the new method? Then I vote for merging. |
|
Ready for review. |
9356b27 to
fb205d2
Compare
test/nullable.jl
Outdated
|
|
||
| @test_throws UndefRefError unsafe_get(Nullable()) | ||
|
|
||
| # unsafe_get(x) |
There was a problem hiding this comment.
Could as well merge this loop with the one above.
There was a problem hiding this comment.
I suppose? But it doesn't need to be executed multiple times.
EDIT: Oh wait, misread this. Yes, I agree.
test/nullable.jl
Outdated
| @test unsafe_get(x4) === a | ||
| end | ||
|
|
||
| @test_throws UndefRefError unsafe_get(Nullable()) |
There was a problem hiding this comment.
Maybe also test with another type, e.g. Nullable{String}()?
|
|
||
| get(x::Nullable) = x.isnull ? throw(NullException()) : x.value | ||
|
|
||
| unsafe_get(x::Nullable) = x.value |
test/nullable.jl
Outdated
| @test isnull(Nullable()) | ||
|
|
||
| # isnull(x) | ||
| for T in types |
|
I've added a docstring for |
base/nullable.jl
Outdated
|
|
||
| Return the value of `x` for `x::Nullable`; return `x` for all other `x`. | ||
|
|
||
| Unsafe because does not check whether or not `x` is null before attempting to |
There was a problem hiding this comment.
Maybe "This function is unsafe because it does not..."?
e64b787 to
ef546f5
Compare
|
@nalimilan How's this? |
| """ | ||
| unsafe_get(x) | ||
|
|
||
| Return the value of `x` for [`Nullable`](:obj:`Nullable`) `x`; return `x` for |
There was a problem hiding this comment.
Just being curious, do we need this to get links?
There was a problem hiding this comment.
That's my understanding. @kshyatt included these in https://github.com/JuliaLang/julia/pull/18511/files#diff-1955b2684af6e5a407aa36281f8bafdeR94, so I figured I'd include them here, too.
There was a problem hiding this comment.
Is this documented somewhere? Maybe somebody could add a word about this at http://docs.julialang.org/en/latest/manual/documentation/? @MichaelHatherly
(FWIW, the repetition of the object name sounds a bit annoying to me...)
There was a problem hiding this comment.
That syntax is being removed in #18588 in favour of [Nullable](@ref), so probably no need to add it to the docs at this point.
so I figured I'd include them here, too.
We can never have too many cross references 👍
There was a problem hiding this comment.
Okay, I'll remove the references for now. I think we will all live with the repetition in the docstring.
There was a problem hiding this comment.
does the auto conversion script translate them from the current rst-in-markdown hybrid to the new style? if so it won't hurt to add if this gets merged before the conversion
There was a problem hiding this comment.
Yes, handled automatically. It's fine to keep adding xrefs.
There was a problem hiding this comment.
Okay, I will add it back in.
Also move isnull docstring out of helpdb and into base/nullable.jl.
|
I think everything is good here. @nalimilan ? |
|
These docstrings need to be added to the manual if this is exported |
|
This was also missing a |
| isnull(x::Nullable) = x.isnull | ||
| isnull(x) = false | ||
|
|
||
| isnull(x::Nullable) = !x.hasvalue |
|
Yeesh, who knew I was such a scrub. I'll fix this and the documentation bit On Monday, October 3, 2016, Tony Kelman notifications@github.com wrote:
|
|
@tkelman should I revert this or put those fixes in a new PR? EDIT: Also, what precisely do you mean by "add docstrings to the manual" ? |
|
little cleanup in a new pr is all that's needed, it's not that bad |
It would be useful to have a generic fallback for
isnullwhen operating on iterators (usually tuples) of bothNullableand non-Nullableobjects. Is there anything else we need to do here to make sure this is optimized away in the case of non-Nullablearguments? What should tests look like?cc: @johnmyleswhite @nalimilan @quinnj