J3/02-306 Date: October 25, 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").