I agree with Tom that SELECT TYPE and SAME_TYPE_AS ought to be
consistent.

On Tue, 2017-07-18 at 12:51 +0000, Clune, Thomas L. (GSFC-6101) wrote:
> Ouch.  Granted that I use this rarely, and mostly in the well-defined
> context of an inheritance tree.   But now I need to go and look to see
> if I have any ticking bombs in code that use CLASS(*). 
> 
> 
> I think that a strong case should be made that the behavior of this
> intrinsic should be consistent with SELECT TYPE which does really end
> up being SELECT TYPE AND KIND.
> 
> 
> > On Jul 17, 2017, at 10:08 PM, Malcolm Cohen <[log in to unmask]>
> > wrote:
> > 
> > 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,
> > -- 
> > ..............Malcolm Cohen, NAG Oxford/Tokyo.
> >  
> > From: Fortran 90 List [mailto:[log in to unmask]] On
> > Behalf Of Van Snyder
> > Sent: Saturday, July 15, 2017 5:34 AM
> > To: [log in to unmask]
> > Subject: Re: [COMP-FORTRAN-90] Misuse of same_type_as intrinsic?
> >  
> > 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.
> > 
> > 
> 
>