J3/04-407r1 Date: 9 Nov 2004 To: J3 From: Richard Maine/Dick Hendrickson Subject: Simplified KIND selection - Specs and illustrative syntax References: J3/04-240 INTRODUCTION This paper proposes specs and illustrative syntax for simplified kind selection. The proposal for this feature was originally submitted as 04-240 and garnered strong support, as documented in 04-302. REQUIREMENTS Requirements were outlined in 04-240. In short review, the requirement is to provide a simplified means to select the most commonly desired real and integer kinds. SPECIFICATIONS Several possible approaches were outlined in 04-240. I propose that we adopt the approach that is intermediate in complexity, namely that the standard define named constants for the most commonly desired real and integer kinds. The approach of standardizing specific kind values would be simpler, but seems overly restrictive. It also raises issues of compatibility with existing code and compilers, which would turn this otherwise simple proposal into a much larger issue. The edits might be small, but the implications would not be. The approach of extending the selected_*_kind intrinsics or adding new similar ones would provide more flexibility and lessen the confusions involved in translating user requirements into decimal digits of precision. However, it does not do much about simplification, which is the primary requirement here. The approach of standardizing some named constants seems adequately simple without being restrictive or raising compatibility issues. It also has the advantage of being completely trivial to implement. My proposal is restricted to kinds with exact sizes. Adding too many options would increase the complexity of the choice to be made by users and would result in issues of interoperability of codes where different users made different choices of how to specify the kinds. Note that the existing selected_*_kind intrinsics provide the capability of specifying minimum requirements and could be extended in many ways (although that is not proposed here). Exact sizes are the simplest and most commonly requested requirement, and one that the standard currently provides no facility for (except in C interop, which has it only for integers - nor for reals). I also restrict the proposal to integers and reals because they are the common cases. User specification of specific sizes for logical kinds is rare (and even more rare when you rule out the cases where logical is being used as a synonym for unsigned integer, which is a nonstandard and nonportable practice anyway). User specification of character kinds is also rare. Therefore, I propose that the specifications be: The standard will specify the names of several named constants in the ISO_FORTRAN_ENV intrinsic module. These named constants will have kind values for the representations described below. Named constants provided will be for the kinds of integers whose storage sizes are exactly 8, 16, 32, and 64 bits, and for the kinds of reals whose storage sizes are exactly 32, 64, and 128 bits. Additionally, named constants will be provided for the kinds of default integer, default real, and double precision real. If the processor supports more than one representation with the specified size, it is processor-dependent which of those representations the named constant corresponds to. If the processsor does not support a particular representation, the value of the corresponding named constant will be one of two negative values specified by the standard. If the processor does not support a representation with the exact size requested or with any larger size, the value shall be -1. If the processor does not support a representation with the exact size requested, but does support a representation with a larger size, the value shall be -2. This proposal does not require the compiler to support any particular kind. Nor does this proposal specify the kind values, which remain processor-dependent. ILLUSTRATIVE SYNTAX This syntax suggestion is purely illustrative for now. It seems too early to debate exact names when it is not yet decided what things need names and what the meaning would be. The exact names are really the only syntax matter relevant to the proposed specifications. If the above specifications are accepted, a possible set of names is: int8_kind, int16_kind, int32_kind, int64_kind real32_kind, real64_kind, real128_kind int_default_kind, real_default_kind, real_double_kind