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
>
>
