Right - I got myself in a muddle in my last post. It seems clear that the new system should be easier to comprehend.
With regard to ANY, I think I was really looking for more control over how things dispatch. For instance if ANY = T where T<:Any then I might consider ANYFLOAT = T where T<:AbstractFloat. So it would be a method that dispatches only on AbstractFloat (because that is the only case the generic method makes sense, and maybe there are other methods) but we don’t want a specialised compilation (compiler overhead being estimated as worse than run time penalty).
Where this is coming from is our previous discussion on improving the performance of Union. Specifically, if we update the internal layout (“box”) for a Union type, then we will be able to use that layout in ccall. Is it useful or desirable to let users create a generic Julia function that can also take advantage of this new kind of box, only specialised for the union rather than each concrete type, in the same way that ANY lets us use the existing box?
Otherwise, to achieve this, users would have to use a wrapper type (an immutable Ref type of container) or call cfunction and ccall. I was wondering if we can fit all of this into the new where syntax or modify ANY to something like typealias ANY{T where T} T such that ANY{Union{A,B}} uses the new box, or something.