Date: 29 May, 2000
Subject: Miscellaneous edits
References: 00-007r1, 00-192r1, 00-201
Paper 00-192r1 raises a number of potential issues. Three of these (all on
page 57 of 00-007r1 deal with TYPEALIAS. /interop believes the first and
third of these are integration issues, and that the second issue asks if a
clause is unnecessary. /interop believes it is not only unnecessary, but
wrong as a circular definition results. Edits are provided for the first
and third issues that introduced unresolved issues keyworded "Integration",
and an edit to correct the second issues.
Paper 00-201 part 2 points out typos in section 4.7, ENUMs. Edits are
provided to correct these.
[57:38-39] delete ", nor the same as any other accessible <type-alias-name>
or derived type <type-name>.
[57:41] add "J3 internal note
Unresolved issue 270: Integration
<declaration-type-spec> includes "CLASS(...)". It was not the
intent of /interop to allow classes in TYPEALIAS statements. Is
the correct fix to change <declaration-type-spec> to <type-spec>?
J3 internal note
Unresolved issue 271: Integration
Can a type alias name be used as the parent type name in an
extended type declaration (probably not), or can an parent type
of an extended type have a type alias (probably)? Should some-
thing be said (perhaps a constraint) to disallow a type alias
name from being used to specify the parent type of an extended
[59:18] change "(724)" to a section reference 7.5, "(7.5)"
[59:38] change "PARAMATER" to "PARAMETER"
[58:21,23] Add the keywords ENUM and EMUMERATOR to the index.