To: J3                                     J3/08-268
From: Dan Nagle
Subject: PC J32026 becomes an Interp
Date: 2008 August 14

Robert Corbett submitted Public Comment J32026,
which was answered by /Data in 08-240r1 as being
an appropriate topic of an Interp.

I reformatted the PC as an Interp to offload
some work from an overworked /Data at m185.

NUMBER: F03/		! /interp assigns number after submission
TITLE: 	Implicit typing in derived types
KEYWORDS: Derived types, implicit typing
DEFECT TYPE: 		! /interp assigns
STATUS: J3 consideration in progress

QUESTION:

This is from Robert Corbett via f08 PC J32026 a/k/a 08-240.
AT 185, 08-240r1 suggested making this an Interp.  Done herewith.

Consider the program

       PROGRAM MAIN
         TYPE T
           INTEGER :: I = BIT_SIZE(J)
         END TYPE
         CALL SUBR1
       CONTAINS
         SUBROUTINE SUBR1
           J = 1
           CALL SUBR2
           PRINT *, J
         END SUBROUTINE
         SUBROUTINE SUBR2
           J = 2
         END SUBROUTINE
       END

This program prints either 1 or 2 depending on the
implementation with which it is compiled.  Some
implementations implicitly declared J in the
top-level scope of the main program.  Some declare
J in the scope of the derived type definition, which
is semantic nonsense, but there you have it.

ANSWER:

Paragraph 4 of Section 5.5 of the Fortran 2008 draft
states

     The data entity is treated as if it were
     explicitly declared in the outermost scoping
     unit in which it appears.

The derived type definition is the outermost scoping
unit in which the occurrence of J in the derived type
definition appears, but an explicit definition of J
is not allowed in that context.

The simple solution for this problem is to ban implicit
typing in derived type definitions.

EDITS: none supplied

SUBMITTED BY: Robert Corbett (via Van Snyder via Dan Nagle)

HISTORY: 08-240    m185  F03/nnnn Submitted

Submitted during Public Comment processing at m185