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.
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 <https://github.com/JuliaLang/julia/issues/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.
>>>
>>
>>
