J3/02-306r1
Date: November 14, 2002
To: J3
From: Rob James
Subject: Problems with Type Aliases
Introduction
------------
Type alias names and derived type names should behave essentially
the same in most situations. They are both just names of types.
They are both used in the same way to declare objects. They
should abide by the same rules, as far as declaring an entity
goes. Right now, they don't.
Type Alias Problem #1:
----------------------
Type aliases may not be extended. Don't say otherwise.
Note 4.45 (page 54, after line 5 in the Committee Draft) says that
the name of a parent type might be a type alias name. This was
true in a previous draft, but not in the Committee Draft. The
words "a name or" should be removed from this note.
Type Alias Problem #2:
----------------------
It's not clear, except from an example in a note, that a
in a TYPEALIAS statement can specify a
type alias.
Sure, I suppose that if a in a TYPEALIAS
statement specifies a type alias, it is really specifying the
type and type parameters being aliased by that type alias. After
all, it does say below that declaration of an entity using a type
alias name has that effect (page 61, lines 12-13 of the Committee
Draft). But it would really make things more clear if type alias
names were explicitly allowed in this case.
I suggest that constraint C480 (page 61, lines 10-11 of the
Committee Draft) be changed to the following:
(R453) A shall specify an intrinsic
type, a previously defined derived type, or a previously
defined type alias.
This also covers situations like the following:
TYPE :: dt
...
END TYPE
TYPEALIAS :: ta => TYPE(ta2)
TYPEALIAS :: ta2 => TYPE(dt)
Without this change to the constraint, there is nothing
prohibiting the user from specifying a type alias that is defined
later in that scoping unit (there is such a rule for derived
types).
Type Alias Problem #3
---------------------
If a derived type is specified in a function prefix, it can be
defined inside the function. Can the same be done with type
aliases?
I would think the same could be done with type aliases. The
syntax looks the same for derived types and type aliases on a
function prefix. One would think that if you specify TYPE(NAME)
in a function prefix, then NAME could be legally defined inside
the function, whether it's a derived type or a type alias.
As it stands, there is nothing that says this is allowed for
type aliases. I suggest that 5.1.1.7 be renamed to "TYPE" rather
than "Derived type". 5.1.1 is called "Type specifiers". "TYPE"
is the type specifier for derived types and type aliases. (In a
similar vein, 5.1.1.8 should be renamed to "CLASS", because it
talks about the CLASS type specifier.) If this is done, something
about type aliases could easily be added into 5.1.1.7 (such text
doesn't already exist in this chapter). The part about derived
types that are specified on FUNCTION statements could be expanded
to include type aliases.
Proposed Edits
--------------
Page and line numbers refer to the Committee Draft.
To fix problem #1:
[54:5+] In the first line of Note 4.45, remove
"a name or".
To fix problem #2:
[61:10] Replace "or" with ",".
[61:11] After "type" (before the period), add
", or a previously defined type alias".
To fix problem #3:
No edits. This is covered in another paper ("Function prefixes
and specification inquiries").
J3 Response: J3 will recommend that these changes be made to the
Committee Draft.