https://github.com/JuliaLang/Compat.jl#new-types
--Tim On Saturday, May 30, 2015 04:50:07 AM Tobias Knopp wrote: > Yes thats true but thats the future and currently not in stable Julia. > > Am Samstag, 30. Mai 2015 12:39:10 UTC+2 schrieb Jiahao Chen: > > For this use case of optionally present data, Nullable would seem > > appropriate (although this is 0.4-only). > > > > > > http://julia.readthedocs.org/en/latest/manual/types/#nullable-types-repres > > enting-missing-values > > > > Thanks, > > > > Jiahao Chen > > Research Scientist > > MIT CSAIL > > > > On Sat, May 30, 2015 at 2:08 PM, Tobias Knopp <[email protected] > > > > <javascript:>> wrote: > >> There is one exception though, which is keyword arguments > >> > >> Am Samstag, 30. Mai 2015 03:49:45 UTC+2 schrieb Steven G. Johnson: > >>> *No!* This is one of the most common misconceptions about Julia > >>> programming. > >>> > >>> The type declarations in function arguments have *no impact* on > >>> performance. Zero. Nada. Zip. You *don't have to declare a type at > >>> all* in the function argument, and it *still* won't matter for > >>> performance. > >>> > >>> The argument types are just a filter for when the function is > >>> applicable. > >>> > >>> The first time a function is called, a specialized version is compiled > >>> for the types of the arguments that you pass it. Subsequently, when you > >>> call it with arguments of the same type, the specialized version is > >>> called. > >>> > >>> Note also that a default argument foo(x, y=false) is exactly equivalent > >>> to defining > >>> > >>> foo(x,y) = ... > >>> foo(x) = foo(x, false) > >>> > >>> So, if you call foo(x, [1,2,3]), it calls a version of foo(x,y) > >>> specialized for an Array{Int} in the second argument. The existence of > >>> a > >>> version of foo specialized for a boolean y is irrelevant.
