From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org  Wed Mar 26 03:06:51 2014
Return-Path: <owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org>
X-Original-To: sc22wg5-dom8
Delivered-To: sc22wg5-dom8@www.open-std.org
Received: by www.open-std.org (Postfix, from userid 521)
	id 137AA358651; Wed, 26 Mar 2014 03:06:51 +0100 (CET)
Delivered-To: sc22wg5@open-std.org
X-Greylist: delayed 1455 seconds by postgrey-1.34 at www5.open-std.org; Wed, 26 Mar 2014 03:06:49 CET
Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109])
	by www.open-std.org (Postfix) with ESMTP id DD70E356D97
	for <sc22wg5@open-std.org>; Wed, 26 Mar 2014 03:06:48 +0100 (CET)
Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57])
	by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s2Q1gRUD006107
	(using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO)
	for <sc22wg5@open-std.org>; Tue, 25 Mar 2014 18:42:29 -0700
Subject: New types from old
From: Van Snyder <Van.Snyder@jpl.nasa.gov>
Reply-To: Van.Snyder@jpl.nasa.gov
To: sc22wg5 <sc22wg5@open-std.org>
Content-Type: text/plain; charset="ISO-8859-1"
Organization: Yes
Date: Tue, 25 Mar 2014 18:42:27 -0700
Message-ID: <1395798147.18609.130.camel@math.jpl.nasa.gov>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.3 (2.32.3-30.el6) 
Content-Transfer-Encoding: 7bit
X-Source-Sender: Van.Snyder@jpl.nasa.gov
X-AUTH: Authorized
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

I've already described the problem that SELECTED_REAL_KIND(6) and
SELECTED_REAL_KIND(12) yield different kind type parameter values with
some processors, and the same kind type parameter value with other
processors.  This militates against portability:  If one has a generic
procedure in which one specific has arguments with SELECTED_REAL_KIND(6)
and another has arguments with SELECTED_REAL_KIND(12), it will work fine
in the first environment, but won't even compile in the second.

New types from old, rather than type synonyms, would solve this problem,
as I've previously explained.

Nick's discomfort concerning the intent of the SOURCE argument of
collective subroutines that have an optional RESULT argument would yield
to a use of new types from old.

If the type of the RESULT argument of those collectives were required to
be an extension of the type of the SOURCE argument, it would be possible
to have two argument lists, one with RESULT and one without.  In the one
without RESULT, the SOURCE argument would have INTENT(INOUT), while in
the one with RESULT it would have INTENT(IN).

What to do if SOURCE is of intrinsic type?

Define a new type.  If new types from old are defined to be extensions,
for which no syntax is provided to add components, type parameters, or
type-bound procedures, and intrinsic operations on intrinsic types are
defined to be bound to the intrinsic types, all existing rules for
generic resolution, argument association, and inheritance work.

There is nothing that can be done using type synonyms that cannot be
done with new types, so both mechanisms are not needed.  There are
things that can be done with new types that cannot be done with type
synonyms, so if anything in this direction is done, it ought to be new
types from old, not type synonyms.