I'm pretty sure I convinced Jeff that we should change ambiguities, at least between modules, into runtime errors instead of definition-time warnings. So you can expect this to change in the future. Of course, that doesn't help right now.
On Thu, Jan 21, 2016 at 6:06 PM, Tim Holy <[email protected]> wrote: > There is a solution, but no one (including me) has yet gotten around to it: > > https://github.com/JuliaStats/DataArrays.jl/issues/168 > > The more general solution is to turn ambiguity warnings into automatically- > (and silently-)generated "stub" functions that throw an error when called. > However, I think that's waiting on an overhaul of the type system. > > Best, > --Tim > > On Thursday, January 21, 2016 01:44:49 PM Mauro wrote: > > It's a known wart: https://github.com/JuliaLang/julia/issues/6190 > > > > But as far as I recall that issue thread, no solution has been found yet. > > > > On Thu, 2016-01-21 at 13:32, [email protected] wrote: > > > Just wondering if there's a solution in the future for this trivial but > mildly irritating problem: > > > julia> using DataFrames, Images > > > WARNING: New definition > > > > > > .+(Images.AbstractImageDirect, AbstractArray) at > > > /Users/me/.julia/v0.4/Images/src/algorithms.jl:22> > > > is ambiguous with: > > > .+(AbstractArray, Union{DataArrays.PooledDataArray, > > > DataArrays.DataArray}, AbstractArray...) at > > > /Users/me/.julia/v0.4/DataArrays/src/broadcast.jl:297.> > > > To fix, define > > > > > > .+(Images.AbstractImageDirect, > Union{DataArrays.PooledDataArray, > > > DataArrays.DataArray})> > > > before the new definition. > > > > > > and so on for 150 lines. It's not a major problem, of course (I just > > > ignore it). But I'm curious as to what the fix will be. > >
