[J3] type definitions

Malcolm Cohen malcolm at nag-j.co.jp
Sun Aug 14 01:09:42 UTC 2022

Van is correct.


Component names are class (3), Variable names are class (1), so there is no conflict – our rules permit this.


A structure component name is never “bare”, it is always preceded by a percent sign.


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.


So, no conflict and no ambiguity.




..............Malcolm Cohen, NAG Oxford/Tokyo.


From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Van Snyder via J3
Sent: Sunday, August 14, 2022 5:47 AM
To: j3 at mailman.j3-fortran.org
Cc: Van Snyder <van.snyder at sbcglobal.net>
Subject: Re: [J3] type definitions


On Sat, 2022-08-13 at 14:38 -0500, Kurt W Hirchert via J3 wrote:

On 8/10/2022 5:18 PM, Robert Corbett via J3 wrote:


Is the program


        TYPE T
          REAL(KIND=KIND(X)) Y
        END TYPE T

standard conformant?

What about the program

        TYPE T
          REAL(KIND=KIND(X)) X
        END TYPE T


Some of the text in the Fortran 2008

standard and Corrigendum 1 that

applies to these programs seems to

be missing in the Fortran 2018 

standard and the 2023 draft.

Robert Corbett


Several people have said thought that both programs conform.  I come to a different conclusion, so I would appreciate it if people could point out where they disagree with my reasoning.  (It's been nearly two decades since I was on the committee, so my grasp of the fine details of the standard may not be what it used to be.)

I see the first program as conforming, independent of the question of the "missing" text.  Since X is not declared explicitly, it is implicitly declared to be default real, so the KIND for Y is established regardless of the question of whether X is a part of T or of MAIN.  For reasons having nothing to do with this example, it is important that X not be part of T (because we don't want undeclared components in T), so I hope that Malcolm's comments that the "missing" text was unnecessary means that this is expressed more clearly somewhere else in the draft.  Could we get a hint as to where?

I see the second program as not confirming.  The explicit declaration of a component X in T prevents T from accessing the X in MAIN by host association, so KIND(X) can only be referencing the component X, but this violates the requirement that the explicit declaration of X precede the KIND(X) reference.  I can imagine reasons why a compiler might fail to diagnose this, so I don't take compiler acceptance of this program as a strong indication of how the standard should be interpreted in this regard.

Am I missing something?


I don't think the reference to KIND(X) in the second example is a reference to the to-be-defined component. There is no syntax to reference a component of a type from within the type, or indeed anywhere else. Only the components of objects of the type can be accessed, and then they need the <designator>% before the component name.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20220814/edad0b20/attachment.htm>

More information about the J3 mailing list