ISO/IEC JTC1/SC22/WG5 N1510 Convener's analysis of the ballot John Reid I have studied all the ballot comments (N1506 and N1509) and the comment from Australia (N1499) and constructed a first draft response (N1511). This includes the suggestion that WG5 defers the following comments to J3 to take whatever action it considers appropriate: US: All of section 1, except 1.12, 1.14, 1.20, and 1.21. Sections 2.4, 2.6, 2.10, 2.11, 2.12, 2.16. UK: Suggestions MTC2, MTC3, MTC4, MTC5, MTC8, E1-E22. JAPAN: All suggestions. AUSTRALIA: Change the remarks on module processing in Annex C. It also includes the suggestion that WG5 considers explicitly the following technical changes (grouped by potential subgroups): Interop. US 1.14 Cater for the C types int8_t, int16_t, int32_t, int64_t, and intptr_t US 2.5 Require the BIND attribute in the ENUM feature UK TC9 and D i) Remove the ENUM facility. UK MTC11 and D i) Have separate types for C data and procedure pointers UK MTC12 Make TYPE(C_PTR) be an opaque derived type UK MTC13 Require the prototype of an interoperable C function not have the inline function specifier UK MTC14 Add further requirement for C interoperability i/o US 2.9 Replace the constants IOSTAT_END and IOSTAT_EOR by intrinsic functions US 2.13 Add constants to specify the size in bits of the file storage unit, numeric storage unit, and character storage unit UK TC1 Provide more support for ISO 10646 UK MTC6 and D i) Change ACHAR(10) syntax within stream i/o UK MTC7 and D i) Allow input/output of IEEE exceptional values UK MTC15 Specify that the PROCESSOR_DEPENDENT i/o rounding mode should not depend on the rounding mode used for arithmetic Procedures and modules US 1.12 Add KIND parameter to IACHAR US 2.8 Should the transformational intrinsics such as CSHIFT be applicable to array of types with allocatable component? If so, exactly what is meant? US 2.14 Decide whether a program can have an intrinsic and nonintrinsic module of the same name UK MTC9 Allow for IEEE extended format UK MTC10 Add a facility for controlling IEEE underflow D k) Incorporate Van Snyder's TR into Fortran 2000 Data US 1.20 Rename NONKIND as EXTENT UK MTC1 Reword "NONKIND" as "LEN" US 1.21, UK TC2, D i) Do not allow the parent component of a type to be specified as private UK TC2 and D i) Remove the option of re-specifying the default initial value for the parent component when a type is extended US 2.1 and 2.7a Give any object of CLASS(T) a component named T that represents its TYPE(T) subobject US 2.2a Add optional MOLD argument to ALLOCATE to specify the dynamic type in the polymorphic case US 2.2b Make intrinsic assignment apply to the dynamic type US 2.3 Reinstate deferred bindings US 2.7b Disallow type mismatches when the dummy argument is declared with TYPE rather than CLASS US 2.15 Allow BOZ constants to have a kind type parameter value UK TC3 and D i) Allow default initialization of parameter values of derived types UK TC4 Change type-bound generics to be sets of specific named type-bound procedures. UK TC5 Remove the facility to add type parameters during type extension. UK TC6 and D i) Allow a CLASS(*) pointer to point to an object of any type, including an intrinsic type. UK TC7 Allow any non-SEQUENCE type to be extended. UK TC8 and D i) Remove the TYPEALIAS facility UK TC10 and D h) Treat the assignment to an allocatable array in the same way as to an allocatable array component UK TC11 Allow reallocation of allocatable arrays D m) Remove [ and ] as alternatives to (/ and /)