To: J3                                                     J3/22-205
From: Malcolm Cohen
Subject: Scope of component names
References: J3/22-203
Date: 2022-October-26

1. Response to 22-203

The second sentence of 19.3.4 Components, type parameters, and bindings
says (of a component name)

      Outside of the type definition, it may also
      appear within a designator of a component of
      that type or as a component keyword in a
      structure constructor for that type.

22-203 says
   "the wording makes it seem that the uses in a designator or as
    a component keyword are allowed only outside the type definition"

The wording does not say that, and if it did say that it would not be a
problem, as it would be true. That is because the declaration of an object
of a type, and thus its designator, is not allowed before the type has been
defined. Structure constructors are similarly constrained.

22-203 continues
    "Also, the word "also" suggests that there is some other use of
     component names outside type definitions."

I do not agree that is suggests such an interpretation. Following on from
the first sentence of that paragraph,
    "A component name has the scope of its derived-type definition.",
the word "also" means "apart from that". It is sufficiently unusual for
there to be any use of a name outside its scope that this is quite
reasonable wording, which is why it has been like that for over thirty
years without complaint.

The edits in paper 22-203 suggest "can appear only", i.e. the word "only"
has crept in. This sounds like we are describing some kind of restriction,
and is not appropriate here where we are explaining the opposite of a
restriction.

22-203 states
    "Parallel issues arise for the second and third sentences of 19.3.4."

Parallel responses arise.

It must be admitted that there is no need for these paragraphs to give
permission, and although there is no problem with them doing so, I would
agree that "can" would be better than "may". (In the distant past we often
used "may" in a casual way to mean capability; which might well have been
in accordance with ancient ANSI drafting rules.)

Also I note that paragraph five of this subclause uses "may appear only":

    "A component name or binding name may appear only in a scope in which
     it is accessible."

Although I think that language is permitted by ISO, and expresses a
requirement, the more direct wordings
    "shall appear only" (for a requirement),
or
    "can appear only" (if we are merely noting a requirement elsewhere)
would, I think, be better. And although I believe the accessibility rules
are adequately stated elsewhere, for now I would suggest keeping this as a
requirement with "shall". (I will also note that "may appear only" is
ambiguous in English, which is another good reason for avoiding it.)


2. Edits to N2209

[529] 19.3.4 Components, type parameters, and bindings,
       first three paragraphs,
       change "may" to "can" in each paragraph.

[529] Same subclause, paragraph five,
      change "may appear only" to "shall appear only".

===END===