Derived-Type Definition Overview The general form of a type definition (R429) is:

TYPE [ [ , type-attribute-list ] :: ] type-name [ (type-parameter-name-list) ] [ type-parameter-definition-statement ] ...

[ private-or-sequence-statement ] ...

[ component-definition-statement ] ...

[ procedure-binding-part ] END TYPE [ type-name ]

where the first statement in the definition is called the derived-type statement.

A type attribute (R431) is one of:

access-spec

EXTENDS(parent-type-name) ABSTRACT

BIND (C)

where an access specification is either PRIVATE or PUBLIC and a private-sequence statement is PRIVATE or SEQUENCE. Accessibility (PRIVATE and PUBLIC) and SE-QUENCE are discussed in 4.4.5 and 4.4.10.

The same type attribute must not appear more than once in a given derived-type statement. The same private or sequence statement must not appear more than once in a given type definition.

The name of the type is type-name. If the END TYPE statement has a type name, it must be the same as the one in the derived-type statement.

Type parameters are declared by the type parameter name list and type parameter definition statements; components are defined by the component definition statements;

and procedure bindings are defined by the procedure binding part. The EXTENDS and ABSTRACT type attributes relate to type extension and extended types (4.4.12). The BIND attribute declares a derived type to be interoperable. Interoperable types are sub-ject to additional restrictions described in 15.

Contrary to some expectations, the order of the component declaration statements does not imply a storage order, except in the cases of sequence and bind types (4.4.10).

4.4.3 Type Parameters

A derived type is said to be parameterized if it has any type parameters. The parame-ters of a derived type are specified by the type parameter name list in the derived-type statement. For an extended type (4.4.12), the type parameters are those of the parent type, followed by those specified by the type parameter name list of the extended type.

Additional information about a type parameter is specified by a type parameter definition statement (R435), which has the form:

82 Chapter 4

INTEGER [ ( [ KIND= ] kind-value) ] ,kind-or-len::type-parameter-declaration-list where kind-or-len is KIND or LEN, specifying whether the type parameters named in the list are kind or length parameters. A type parameter declaration (R436) has the form:

type-parameter-name [ =scalar-integer-initialization-expression ]

Each type parameter name in a type parameter declaration must be one of the type pa-rameter names specified in the derived-type statement. Each type papa-rameter name in the derived-type statement must appear in exactly one type parameter declaration in the type definition.

Each type parameter is of type integer and therefore has a kind type parameter, which is specified by the kind value in the INTEGER type specifier of the type param-eter definition statement. If no kind value appears, the type paramparam-eter is of type de-fault integer. Discussion of the type parameter of a type parameter can be confusing;

fortunately, such discussion is not often needed.

If a type parameter declaration has a scalar integer initialization expression, the ex-pression specifies a default value for the type parameter.

An example of a derived-type definition with some simple type parameter defini-tion statements is:

type :: some_type(KIND, M, N) integer, len :: N, M

integer, kind :: KIND . . .

end type some_type

This example has a kind parameter named KIND, which is likely to be a common style, and also has two length parameters named M and N. A more complicated example is:

type :: matrix(M, N, KIND, K)

integer, kind :: KIND = kind(0.0), K=kind(0) integer(K), len :: M, N

real(KIND) :: body(M, N) . . .

end type matrix

In this example, KIND is a kind parameter with a default that is the kind value for de-fault real. K is a kind parameter with a dede-fault that is the kind value for dede-fault integer.

M and N are length parameters and have kind K. The REAL statement in this example is a component declaration statement (4.4.6). To help clarity of exposition, the above examples use a convention that type parameter names are all upper case; attributes and function names are all lower case.

Data Types 83

4.4.4 Type Specifier

The form of a derived-type specifier (R455) is a generalization of the forms of the in-trinsic type specifiers. Its description is more complicated because it is expressed in general terms which cover having an arbitrary number of type parameters. The form is similar to that of an actual argument list. The general form is:

type-name [ (type-parameter-spec-list) ] where a type-parameter-spec (R456) is:

[ type-parameter-name= ] type-parameter-value

Type parameter values are described in 4.2.3; the following rules and restrictions apply in addition to those of that section.

Rules and restrictions:

1. The type-name must be an accessible name of a derived type.

2. Each type parameter name must be the name of a type parameter declared in the type definition.

3. Each type parameter of the derived type may have no more than one correspond-ing type parameter specification.

4. Each type parameter of the derived type must have a corresponding type parame-ter specification unless that type parameparame-ter has a default value, as specified in its type parameter definition statement.

5. If a type parameter specification specifies a type parameter name, all subsequent type parameter specifications in the list must also specify a type parameter name.

6. A type parameter value for a kind type parameter must be a kind value (4.2.3); a type parameter value for a length type parameter must be a length value (4.2.3).

7. If the type name is the name of an abstract type, the derived-type specifier can ap-pear only in a CLASS declaration.

The correspondence between type parameters and type parameter specifications is established as follows: a type parameter specification with a type parameter name cor-responds to the type parameter with that name. The type parameter specifications without type parameter names correspond to the type parameters in type parameter order. The type parameter order of a nonextended type is the order of the type param-eters in the derived-type statement for the type. The type parameter order of an ex-tended type is the type parameter order of the parent type, followed by the type parameters in the derived-type statement for the type in order.

If necessary, each specified type parameter value is converted to the kind of the corresponding type parameter. A type parameter that is not in a particular type param-eter specification list takes its default value.

84 Chapter 4 The following examples of type definition statements use type specifiers for the de-rived-type matrix defined in 4.4.3.

type (matrix(n=10,m=10)) :: x

type (matrix(10,10,kind(0.0),kind(0)) :: y type (matrix(20,10,kind(1.0D0)) :: z

In this example. x%body and y%body are default real with shape [10, 10], while z%body is double precision with shape [20, 10].

4.4.5 Accessibility

For a derived type declared in the specification part of a module, it is possible to spec-ify the accessibility of the derived-type name, its component names, and its procedure bindings. The accessibility is either public or private. If an identifier has public accessi-bility, then it is available for use outside of the module via USE statements. If an iden-tifier has private accessibility, then it may be used only inside of the module where it is defined. This definition of accessibility is inherently related to modules; it would be meaningless to specify accessibility of something not declared in the specification part of a module; therefore, that is not allowed.

It is important to understand that accessibility applies to identifiers (most com-monly names, but also things such as operators, which do not have the form of names).

If, for example, a type name has private accessibility, that means only that the type name may not be accessed via USE statements. It does not prevent objects of that type from being used outside of the module, as long as that use does not involve the type name.

The accessibility of a type name, its component names, and its procedure bindings are orthogonal; all combinations are allowed and meaningful.

The accessibility of a type name may be specified either by an access specification in the derived-type statement or by a separate accessibility statement (5.8.1). If the ac-cessibility of the type name is not individually specified, then that type name has the default accessibility for the module (5.8.1).

Having a private type name substantially restricts the allowable uses of the type outside of the module. In particular, objects of the type cannot be declared outside of the module. However, public objects of the type may be accessed.

The accessibility of a component name is specified by an access specification in the component definition statement. If a component definition statement has no access specification, then the accessibility of that component name is the default component accessibility for the type. The default component accessibility for a type is private if the type definition has a PRIVATE statement preceding the component definition state-ments; otherwise, it is public. A default of public can be specified only by omission of the PRIVATE statement; there is no explicit PUBLIC statement in a derived-type defini-tion. The accessibility of a component is not influenced by the accessibility of the type name or by the default accessibility of the module.

The accessibility of a procedure binding (4.4.11) is specified by an access specifica-tion in the procedure binding statement. If a procedure binding statement has no ac-cess specification, then the acac-cessibility of that binding is the default binding

Data Types 85 accessibility for the type. The default binding accessibility for a type is private if there is a PRIVATE statement in the procedure binding part of the type definition; otherwise, it is public. The accessibility of a binding is not influenced by the accessibility of com-ponents, the accessibility of the type name, or the default accessibility of the module.

Accessibility is not relevant for final bindings (4.4.11.3) because they do not have iden-tifiers.

Accessibility cannot be specified for type parameters. Effectively they are always public.

Example:

type, public :: some_type private

real, public :: x integer :: i,j end type some_type

The type name some_type is public, as is the component name x. The component names i and j are private because of the PRIVATE statement. A scoping unit that uses this module could have a declaration like

type(some_type) :: z

and could then refer to z%x. The only way to access the i and j components of z would be by means of some procedure defined in the same module that defines the type.