Either that or there's some convert method that violates that expectation,
in which case inference would correctly decide that it can't predict the
result type.

On Mon, Jun 1, 2015 at 6:05 PM, Yichao Yu <yyc1...@gmail.com> wrote:

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

Reply via email to