(j3.2006) derived types with type parameters are different

[Robert Corbett]

Aleksandar Donev wrote:
> Jim Giles wrote:
> 
> 
>>KIND type parameters must be initialization expressions.  So all
>>these expressions you've been arguing about *are* compile-time
>>constants. 
> 
> OK, I missed the KIND in the example. In that case, can Robert give an 
> example where it is needed to decide if two types are equivalent? It 
> would seem to me that for kind type parameters the actual decision needs 
> to only be made at a time when the parameter is known (since I believe 
> the kind type can be unknown only in the type declaration, but not in 
> any use of the type, right?). Therefore, N and N+0 no longer involve "N" 
> but are rather 4 and 4 or whatever. That of course a compiler can 
> (already does) and should be able to figure out.

As I said in my response to James Giles, something like that can be
made to work for kind type parameter values.  It won't work for nonkind
type parameters.  The changes to the standard required to describe
something like that are likely to be large.  The concept of derived
types being the same or different depending on the value of a kind
type parameter is foreign to the standard as it is currently written.
When the kind type parameter value determines whether two derived types
are the same type, it no longer makes sense to speak of entities having
the same type and type parameters.  A more complicated notion is needed.

I presented the KIND case first precisely because it could be resolved
in more ways than the nonkind case.  If there was a consensus on the
KIND case and that consensus also applied to the nonkind case, I thought
I might avoid raising the issue of the difference between the two cases.

> Is it ever actually needed to know if two parameterized types are 
> equivalent without knowing the KIND parameters?

Yes.  Consider generic resolution.  Just remove the KIND attribute from
any of the earlier examples given and use those definitions as arguments
in a generic interface.  The same issues would hold as when the KIND 
attribute is present.

> Bill said:
>  > expressions.  At least at the level of knowing that N and N+0 are the
>  > same.  Not quite as clear for Andy's example of N*(N-1) and N*N-N.
> If we are talking about compile-time constants, I don't see any 
> essential or meaningful difference. They are two numbers, which may be 
> the same, or different. Whether they are the same for every N, just this 
> N, or no N, should not matter.
> 
> All I see is "and have type parameters and components that agree in 
> order, name, and attributes." This smells to me like it has not been 
> updated at all for type parameters?!?

The mention of "type parameters" was an update.

> Surely, as Robert suggested, KIND 
> and LENgth should be treated differently?

I was pointing out that the nonkind case could not be treated in the
same way as was suggested for the KIND case.  I was neither recommending
such a solution nor recommending against it.  I thought of many possible
ways of resolving this problem since it occurred to me.  I wish I could
say one of them is clearly superior to the others, but I cannot.

Bob Corbett