Right, the correct way to say this should be Array{Number,1} in a function
signature would not match an input of Array{Int,1} etc. so in your example
if I do
julia> f( [1,2] )
ERROR: `f` has no method matching f(::Array{Int64,1})
Anyway, Lint catches that.
On Sunday, September 14, 2014 8:55:02 AM UTC+7, Keno Fischer wrote:
>
> It's callable, but probably not what you want:
>
> julia> f(A::Vector{Number}) = println(A)
> f (generic function with 1 method)
>
> julia> f(Number[1.0; 1])
> Number[1.0,1]
>
> On Sat, Sep 13, 2014 at 9:51 PM, Tony Fong <[email protected]
> <javascript:>> wrote:
> > I think a container type with a non-leaf eltype won't match anything.
> The
> > right way to declare such a function should be instead
> >
> > function f{T<:Number}( x::Array{T,1} )
> > ...
> > end
> >
> >
> > On Sunday, September 14, 2014 5:09:39 AM UTC+7, Tim Holy wrote:
> >>
> >> Wow, this is really impressive. I'm going to have to take a close look
> >> again.
> >>
> >> What do you mean below about "wrong signatures"? That signature looks
> >> correct
> >> to me, albeit not very useful and probably not what the programmer
> >> intended.
> >>
> >> --Tim
> >>
> >> On Saturday, September 13, 2014 12:34:44 PM Tony Fong wrote:
> >> > Fellow Julians,
> >> >
> >> > I think it is time to post an update on Lint.jl
> >> > <https://github.com/tonyhffong/Lint.jl>, as it has improved quite a
> bit
> >> > from the initial version I started about 3 months ago.
> >> >
> >> > Notable new features
> >> >
> >> > - Local variable type tracking, which enables a range of features,
> >> > such
> >> > as
> >> > - Variable type stability warning within a function scope.
> >> > - Incompatibility between type assertion and assignment
> >> > - Omission of returning the constructed object in a type
> >> > constructor
> >> > - Check the call signature of a selected set of methods with
> >> > collection (push!, append!, etc.)
> >> > - More function checks, such as
> >> > - repeated arguments
> >> > - wrong signatures, e.g. f( x::Array{Number,1} )
> >> > - Mispelled constructor (calls new but the function name
> doesn't
> >> > match the enclosing type)
> >> > - Ability to silence lint warning via lintpragma() function, e.g.
> >> > - lintpragma( "Ignore unstable type variable [variable name]" )
> >> > - lintpragma( "Ignore Unused [variable name]" )
> >> >
> >> > Also, there is now quite a range of test scripts showing sample codes
> >> > with
> >> > lint problems, so it's easy to grep your own lint warnings in that
> >> > folder
> >> > and see a distilled version of the issue.
> >> >
> >> > Again, please let me know about gaps and false positives.
> >> >
> >> > Tony
> >>
> >
>
