> Every call to do_something_with() is made type-uncertain because the type of > x can't be inferred at method-compile-time. So your hot loop is poisoned by > the use of a once-called type-uncertain function.
This is true now, but hopefully either Jameson's code[1] can be made working or Oscar's JSoC idea[2] can be implemented to improve this. [1] https://github.com/JuliaLang/julia/issues/10805 [2] https://github.com/JuliaLang/julialang.github.com/blob/master/gsoc/2015/index.md#project-specialized-call-site-method-caching On Fri, May 29, 2015 at 12:12 PM, andrew cooke <[email protected]> wrote: > > > On Friday, 29 May 2015 10:37:38 UTC-3, Yichao Yu wrote: >> >> On Fri, May 29, 2015 at 9:21 AM, andrew cooke <[email protected]> wrote: >> > >> > Ahh! >> > >> > No, its possible: >> > >> > >> > julia> foo(::Nullable{Union()}) = "empty" >> > foo (generic function with 1 method) >> > >> > julia> foo(::Nullable{Int}) = "int" >> > foo (generic function with 2 methods) >> > >> > julia> foo(Nullable()) >> > "empty" >> > >> > julia> foo(Nullable(4)) >> > "int" >> >> I'm not sure if this is what you want. >> >> The point of Nullable is that it maintains type stability when you >> return "missing value", i.e. the type of a Nullable you should get >> from a function should always be the same (otherwise there's no point >> to use Nullable to begin with). > > > can you expand on this? what if i'm writing some code that constructs > arbitrary types, and i need to know whether the user constructed "anything", > or decided to not do so on this call. wouldn't that be a suitable use of > Nullable{Any}? > AFAIK, the goal of `Nullable` is to improve functions that returns a concrete type or nothing. If `nothing` is returned when "nothing" needs to be returned, the function will not be type stable. Instead, Nullable wraps this special case type instability in a stable type `Nullable{T}` to make type inference happy. To use, you would write ``` f() = <condition> ? Nullable{Int}() : Nullable(1) ``` The return type for both branches are `Nullable{Int}`. The point is to hide this branch from the type inference so dispatching on the return value from such a function won't work (or won't branch). > what if i'm writing some code that constructs arbitrary types If you have a function that can return random types (i.e. not type stable). It is not what Nullable is designed for. IMHO, the dispatch system is not very good at runtime branching. It works the best when it can statically infer the branch/dispatch you are going to take. If the branch you are taking is not known at compile time (i.e. when the function is compiled, you don't know whether the code is going to return something or nothing) you will be better off doing the check/branch manually. > > >> In a function that returns Int or a >> missing value, you return either Nullable(<int value>) or >> Nullable{Int}(). >> >> Unfortunately, this means that you cannot dispatch on the type (since >> there's only one and that's the point). IMHO, depending on your >> usecase, you might be better off branching on whether the Nullable has >> a value. >> >> > >> > >> > Sorry, please ignore!
