On Mon, Jun 1, 2015 at 6:03 PM, Stefan Karpinski <ste...@karpinski.org> wrote:
> Probably not necessary – that code already has more type annotations than it
> needs. The compiler is usually quite good at figuring out types, in this
> case the global sabotages it.
And I guess typeinf gives up because of the number of methods out
there (although seems that typeinf also fail on some of them though).
```julia
julia> length(methods(convert, Tuple{Type{Float32}, Any}))
26
julia> length(methods(call, Tuple{Type{Float32}, Any}))
1
```
>
> On Mon, Jun 1, 2015 at 5:50 PM, Scott Jones <scott.paul.jo...@gmail.com>
> wrote:
>>
>> Does this mean that in all the code that I've written for UTF conversions,
>> I should decorate the results of the convert with ::T to help the compiler's
>> inference?
>>
>> On Monday, June 1, 2015 at 11:31:53 PM UTC+2, Stefan Karpinski wrote:
>>>
>>> There's nothing in the language that forces convert(T,x) to return
>>> something of type T, so type inference has no idea what type b is. The
>>> method that implements Float32(x) is this:
>>>
>>> call{T}(::Type{T}, arg) = convert(T, arg)::T
>>>
>>>
>>> Note the type assertion – so type inference does know the type of the
>>> result. Related: #1090.
>>>
>>> On Mon, Jun 1, 2015 at 5:06 PM, Arch Robison <arch.d....@gmail.com>
>>> wrote:
>>>>
>>>> I was a bit surprised when I tried this example:
>>>> function foo()
>>>> global G
>>>> #b = Float32(G)
>>>> b = convert(Float32,G)
>>>> b
>>>> end
>>>>
>>>> G = 0.5
>>>> println(foo())
>>>> code_warntype(foo,())
>>>> and code_warntype deduced that the type of b is ANY instead of Float32.
>>>> Is this a bug or a feature? If I use the constructor syntax instead (see
>>>> comment in code), then the type of b is deduced as Float32.
>>>
>>>
>
