Actually this behaviour was already the result of a defect report.  Different processors were already giving different answers here, and there was no consensus on what the result should be (and some thought it should be invalid).  So we made it processor-dependent.

 

One issue is that with intrinsic types, SAME_TYPE_AS is almost always insufficient as being REAL does not tell you the kind type parameter (most derived types don’t have type parameters so much less of an issue there).  So the function is basically useless for intrinsic types anyway.  (So some thought that for intrinsic types it should do a type&kind test, as that is what would be actually useful, while others thought it should do just a type test.  And if the standard defined it one way, that would be likely to make things less efficient for everyone everywhere, so there is good reason to leave it alone.)

 

Cheers,

 

 

On Fri, 2017-07-14 at 12:28 -0600, Neil Carlson wrote:

 

 

On Fri, Jul 14, 2017 at 12:23 PM, Van Snyder <[log in to unmask]> wrote:

On Fri, 2017-07-14 at 12:16 -0600, Neil Carlson wrote:
> [...] that the arguments to same_type_as
> cannot have dynamic types that are intrinsic types (non-extensible).
> Is that right?

Intrinsic types cannot be extended, but they can be the dynamic type of
unlimited polymorphic -- class(*) -- variables.

 

Yes, and I do so.  But It is this language in the standard that gives me pause:

 

  If the dynamic type of A or B is extensible, the result is true if and only if

  the dynamic type of A is the same as the dynamic type of B. If neither A

  nor B has extensible dynamic type, the result is processor dependent.

This is interesting and might need to be addressed as a defect.  I can understand that a processor can't give a definitive answer whether two unlimited polymorphic objects that have dynamic types that are sequence types in fact have the same type.  But there's no excuse for not being able to tell the difference between intrinsic types.