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

Reply via email to