In your example, nothing is of type Nothing, which is not a MyType, so the
assignment fails.

Tim, for kw arguments, is it true that new functions are specialized for
each type?  I'm thought that it wouldn't, which would cause the variable to
be an actual Union type if declared as such, and therefore not as
efficient. I'll test this when I get to a computer.

Cheers,
   Kevin

On Thursday, May 8, 2014, Adam Smith
<swiss.army.engin...@gmail.com<javascript:_e(%7B%7D,'cvml','swiss.army.engin...@gmail.com');>>
wrote:

> That doesn't seem to work with composite types and Nothing. Using a
> day-old nightly build:
>
> julia> type MyType; end
>
> julia> example(x::Int, mt::MyType=nothing) = println("in example")
> example (generic function with 2 methods)
>
> julia> example(1)
> ERROR: no method example(Int64, Nothing)
>  in example at none:1
>
> julia> example(1, MyType())
> in example
>
> Which is why I resorted to the Union() stuff.
>
>
> On Thursday, May 8, 2014 10:32:10 AM UTC-4, Tim Holy wrote:
>
> I agree that declaring types is an effective way of increasing clarity.
> (Fundamentally I suspect that suggests inadequacies in our documentation.)
> Aside from the more "valid" use in controlling which version of a function
> will run on which types of data.
>
> However, you don't have to leave off type information from optional
> arguments:
>
> function findsmallest(v::Vector, issorted::Bool = false)
>     if issorted
>         return v[1]
>     else
>         return minimum(v)
>     end
> end
>
> will be callable either as findsmallest(v, false) or findsmallest(v). If
> you do
> supply the extra argument, it must be a Bool. Doesn't that do what you're
> hoping for?
>
>
> You can also supply types to keyword arguments, i.e.,
>
> function findsmallest(v::Vector; issorted::Bool = false)
>
> which will then be callable either as findsmallest(v) or findsmallest(v,
> issorted=true).
>
> --Tim
>
> On Thursday, May 08, 2014 07:00:42 AM Adam Smith wrote:
> > That makes sense. The other (primary) reason I want this is still valid:
> > assisting multiple dispatch (and clarity for other developers) by having
> > the correct types on optional arguments. Since there are no objects for
> > encapsulation of related behaviors, the only good way to explore an API
> > (other than just reading its source) is to use Julia's reflection
> utilities
> > like names() and methods(). I want to be able to use brief function
> names
> > like "add!()" on my types, but if every optional argument requires
> leaving
> > off the type information, there will quickly be ambiguity/collisions
> with
> > the definitions in different places. Since each one is really intended
> for
> > a specific type, having that in the function signature would improve
> > clarity quite a bit. That's why I spent a bit of time trying to
> construct
> > the @optional macro.
> >
> > On Thursday, May 8, 2014 9:18:01 AM UTC-4, Tim Holy wrote:
> > > I'm not sure I understand. Except for one particular situation (tuple
> > > arguments), declaring the type of inputs has no impact on performance.
> The
> > > JIT
> > > will compile a separate version of the function for each different set
> of
> > > input
> > > types. See the "performance tips" section of the manual.
> > >
> > > --Tim
> > >
> > > On Thursday, May 08, 2014 01:34:12 AM Adam Smith wrote:
> > > > Actually performance is one of the reasons I wanted to do it this
> way,
> > > > rather than leaving off type info and just dealing with Anys, which
> is
> > > > slower (and makes multiple dispatch very messy). I will read through
> > > > Julia's parser a bit more and then file an issue.
> > > >
> > > >  a d a m
> > > >
> > > > On May 8, 2014, at 1:25 AM, "Kevin Squire"
> > > > <kevin....@gmail.com<javascript:>>>
> > > wrote:
> > > > > Hi Adam,
> > > > >
> > > > > While working with optional and union types won't be as performant
> as
> > > > > regular types, this seems like it would be useful.  Why don't you
> file
> > >
> > > an
> > >
> > > > > issue?  It might not be easy or feasible to do what you want, but
> it's
> > > > > good to bring it to the attention of the main devs.
> > > > >
> > > > > Cheers,
> > > > >
> > > > >    Kevin
> > > > >>
> > > > >> On Wed, May 7, 2014 at 5:15 PM, Adam Smith
> > >
> > > > >> <swiss.arm...@gmail.com <javascript:>> wrote:
> > >  Did you make any progress on
> > >
> > > > >> this? I tried to do the exact same thing as you, got the exact
> same
> > > > >> error, googled, and found this post. It seems that Julia parses
> > >
> > > default
> > >
> > > > >> values for arguments separately from the name/type of the
> arguments.
> > > > >> This was the macro I attempted:
> > > > >> macro optional(name, ptype)
> > > > >>
> > > > >>     esc(:($name::Union(Nothing, $ptype) = nothing))
> > > > >>
> > > > >> end
> > > > >>
> > > > >> With the desired usage being:
> > > > >> function do_stuff(x::Int, y::String, @optional(z, Float))
> > > > >>
> > > > >>     # do stuff
> > > > >
>
>

Reply via email to