Well, bug is a strong word since what it's doing is correct according to
the documentation. But yes, it seems like tightening those up would be
good. The last equality is already valid:
julia> Wow{Int} <: Foo{Int}
true
Before changing what typejoin does, I think there should be a clearer
definition of what typejoin computes. It's kind of a tricky definition,
however.
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.
>>
>>>
>>>>
>>
