`typejoin` is actually a deliberately informal "give me some common type" function. It's not used, for example, where a true least upper bound would be required. Hence the vague documentation. After this change I think the behavior will be pretty reasonable. I'd describe it as doing a join on the declared hierarchy, followed by keeping parameters that match and fully widening parameters that don't match.
On Wed, Apr 1, 2015 at 5:02 PM, Jeff Bezanson <[email protected]> wrote: > Yep, I agree with all of that. > > On Wed, Apr 1, 2015 at 4:48 PM, Michael Francis <[email protected]> wrote: >> nice, >> >> so to confirm we agree that >> >>> [a,b] >> >> 2-element Array{Wow{K,V},1}: >> >> Should be >> >>> Wow{Int64,_} or Foo{Int64} [ ideally the former ] >> >> and >> >>> [a,b,c,d] >> >> Should be >> >>> Foo{Int64} >> >> and >> >> Wow{Int64,_} <: Foo{Int64) == true >> >> ? >> >> If that is the case then there is a bug today in the typejoin code for the >> a,b,c,d case ? >> >> On Wednesday, April 1, 2015 at 4:33:19 PM UTC-4, Stefan Karpinski wrote: >>> >>> The language does have both Wow{Int64,_} – which can be expressed easily >>> as Wow{Int64} – and Wow{_,Int64} – which has no easy syntax but still exists >>> (you can create a syntax for it with typealias). I'm not entirely clear on >>> what the inconsistency here is, although it would be nice to have a concise >>> definition of what precisely typejoin computes. The help entry for >>> typejoin(T, S) is "Compute a type that contains both T and S", which, while >>> correct, is a bit vague – it could just return Any all the time by that >>> definition. >>>>> >>>>> >>> >>
