F'2018 subclause 19.3.4 paragraph 1 says that "A component name has the scope of its derived-type definition" which seems pretty clear to me, but it doesn't seem to apply in the way that I would expect with many Fortran compilers. Shouldn't all of these uses of component names in a derived type definition resolve to the components with those names, rather than to the names in the enclosing scope?

implicit double precision(b)
integer, parameter :: k1 = selected_int_kind(1)
integer, parameter :: kd = kind(0)

integer(k1) :: foo

type t
integer(kd) foo
integer(kind(foo)) bar
integer(k1) :: baz = kind(foo)
integer :: quux = kind(baz)
end type
type(t) x

if (k1 == kd) stop 'rats'

if (kind(x%bar) == k1) then
print *, "kind(foo) resolves to outer foo for bar"
else if (kind(x%bar) == kd) then
print *, "kind(foo) resolves to inner foo for bar"
else
print *, "can't tell name resolution of foo for bar"
end if
if (x%baz == k1) then
print *, "kind(foo) resolves to outer foo for baz"
else if (x%baz == kd) then
print *, "kind(foo) resolves to inner foo for baz"
else
print *, "can't tell name resolution of foo for baz"
end if
if (k1 == kind(0.d0)) then
print *, "can't tell name resolution of baz for quux because k1 == kind(0.d0)"
else if (x%quux == k1) then
print *, "kind(baz) resolves to inner baz for quux"
else if (x%quux == kind(0.d0)) then
print *, "kind(baz) resolves to implicit outer baz for quux"
else
print *, "can't tell name resolution of baz for quux"
end if
end

On Friday, October 14, 2022 at 1:58:38 PM UTC-4, Peter Klausler US wrote:

> F'2018 subclause 19.3.4 paragraph 1 says that "A component name has the scope of its derived-type definition" which seems pretty clear to me, but it doesn't seem to apply in the way that I would expect with many Fortran compilers. Shouldn't all of these uses of component names in a derived type definition resolve to the components with those names, rather than to the names in the enclosing scope? ..

@Peter Klausler US,

There was a discussion at the J3 Fortran mailing list a couple of months ago whether the editor of the standard (and the chair of the /DATA subgroup) and the de facto final authority on such matters in the language chimed in and whose brief response I reckon covers your inquiry here also: you know the drill, for further details there is the standard and the words in it.

https://mailman.j3-fortran.org/pipermail/j3/2022-August/013836.html

On Friday, October 14, 2022 at 2:40:52 PM UTC-4, FortranFan wrote:
> ..
> There was a discussion at the J3 Fortran mailing list a couple of months ago *where* the editor of the standard (and the chair of the /DATA subgroup) and the de facto final authority on such matters in the language chimed in and whose brief response I reckon covers your inquiry here also: you know the drill, for further details there is the standard and the words in it.
>
> https://mailman.j3-fortran.org/pipermail/j3/2022-August/013836.html

The following example might help in that the editor, per the comments above, would convey the processor here conforms in what it does with the program:

implicit none !<-- note this
integer, parameter :: ik = kind(0)
type :: t
integer(kind=ik) :: foo
integer(kind=kind(foo)) :: bar !<-- what is 'foo' here?
end type
end

C:\temp>gfortran -c p.f90
p.f90:5:27:

5 | integer(kind=kind(foo)) :: bar
| 1
Error: Symbol 'foo' at (1) has no IMPLICIT type

19.3.4 "A component name has the scope of its derived-type definition. Outside the type definition, it may also appear within a designator of a component of a structure of that type or as a component keyword in a structure constructor for that type."

That first sentence must mean *something*, and the second sentence's "it may also appear" implies that a component name *can* appear with a derived type definition.

On Friday, October 14, 2022 at 2:56:29 PM UTC-4, Peter Klausler US wrote:

> 19.3.4 "A component name has the scope of its derived-type definition. Outside the type definition, it may also appear within a designator of a component of a structure of that type or as a component keyword in a structure constructor for that type."
>
> That first sentence must mean *something*, and the second sentence's "it may also appear" implies that a component name *can* appear with a derived type definition.

You can seek further clarification with the committee but chances are nearly 100% that

a) re: "That first sentence must mean *something*", the "something" will *not* extend to instructions such as 'integer(kind(foo)) bar' in the code snippet in your original post.

b) re: "the second sentence's "it may also appear"" does not refer to "type definition" but to a "structure" and a constructor for it where the "structure" - per the standard - is a scalar data object of a derived type.

On Friday, October 14, 2022 at 12:46:26 PM UTC-7, FortranFan wrote:
> On Friday, October 14, 2022 at 2:56:29 PM UTC-4, Peter Klausler US wrote:
>
> > 19.3.4 "A component name has the scope of its derived-type definition. Outside the type definition, it may also appear within a designator of a component of a structure of that type or as a component keyword in a structure constructor for that type."
> >
> > That first sentence must mean *something*, and the second sentence's "it may also appear" implies that a component name *can* appear with a derived type definition.
> You can seek further clarification with the committee but chances are nearly 100% that
>
> a) re: "That first sentence must mean *something*", the "something" will *not* extend to instructions such as 'integer(kind(foo)) bar' in the code snippet in your original post.
>
> b) re: "the second sentence's "it may also appear"" does not refer to "type definition" but to a "structure" and a constructor for it where the "structure" - per the standard - is a scalar data object of a derived type.

https://dictionary.cambridge.org/us/dictionary/english/also - adverb, "in addition to".

Further, type parameter names of a type are in exactly the same scope as its component names, and type parameter names obviously can be used in the scope of a type definition.

On Friday, October 14, 2022 at 10:58:38 AM UTC-7, Peter Klausler US wrote:
> F'2018 subclause 19.3.4 paragraph 1 says that "A component name
> has the scope of its derived-type definition" which seems pretty clear to me,
> but it doesn't seem to apply in the way that I would expect with many
> Fortran compilers. Shouldn't all of these uses of component names in a
> derived type definition resolve to the components with those names,
> rather than to the names in the enclosing scope?

(snip

> type t
> integer(kd) foo
> integer(kind(foo)) bar
> integer(k1) :: baz = kind(foo)
> integer :: quux = kind(baz)
> end type
This isn't so obvious to me.

It might be that the foo inside the structure definition doesn't exist
until after the "end type".

There is a special rule in C that allows structures to have pointers
to their own struct type, even though the struct isn't defined yet.

I suspect you have to read the rules a lot more carefully, to know
exactly when the inside foo exists, enough for kind to apply.
(And as your example shows, it might be different for KIND
than for initializers.)

It is hard for compiler writers to get this right, and so
my best guess is 50% chance you are right and the compiler
wrong.

On Friday, October 14, 2022 at 2:00:25 PM UTC-7, gah4 wrote:
> It is hard for compiler writers to get this right, and so
> my best guess is 50% chance you are right and the compiler
> wrong.

Well, I'm writing the compiler, so I hope that it's both or neither.

On Friday, October 14, 2022 at 3:59:09 PM UTC-4, Peter Klausler US wrote:

> On Friday, October 14, 2022 at 12:46:26 PM UTC-7, FortranFan wrote:
> ..
> > b) re: "the second sentence's "it may also appear"" does not refer to "type definition" but to a "structure" and a constructor for it where the "structure" - per the standard - is a scalar data object of a derived type.
> https://dictionary.cambridge.org/us/dictionary/english/also - adverb, "in addition to".

The "standardese" charters its own course, it feels free to supersede the dictionary or ordinary usage of terms and phrases.

>
> Further, type parameter names of a type are in exactly the same scope as its component names, and type parameter names obviously can be used in the scope of a type definition.

In the case of a type parameter name, the standard states, "A type parameter may be used as a primary in a specification expression (10.1.11) in the derived-type-def . A kind type parameter may also be used as a primary in a constant expression (10.1.12) in the derived-type-def ." This will likely be pointed out as being applicable and also different from the case with the component name, the latter i.e., the component name being used for example in 'integer(kind(foo)) bar' in the code snippet in the original post:

On Saturday, October 15, 2022 at 8:09:45 AM UTC-7, FortranFan wrote:
> > https://dictionary.cambridge.org/us/dictionary/english/also - adverb, "in addition to".
> The "standardese" charters its own course, it feels free to supersede the dictionary or ordinary usage of terms and phrases.

Ok, if you've altered the meaning of the word "also" in the standard, what does it now mean in this context?

On Saturday, October 15, 2022 at 4:44:41 PM UTC-4, Peter Klausler US wrote:

> On Saturday, October 15, 2022 at 8:09:45 AM UTC-7, FortranFan wrote:
> > > https://dictionary.cambridge.org/us/dictionary/english/also - adverb, "in addition to".
> > The "standardese" charters its own course, it feels free to supersede the dictionary or ordinary usage of terms and phrases.
> Ok, if you've altered the meaning of the word "also" in the standard, what does it now mean in this context?

Not sure what you're getting at, however re: the component name, again here's what you can review:

--- text on the J3 mailing list reply from the Editor ---
".. A “bare” type component name can appear only

1. as the name of the component being defined by a component definition statement;
2. as a keyword in a structure constructor for that type.
..."
--- end text ---