The prime motivation for adding a means to specify default initialisation for objects of derived type is a desire to eliminate memory leakage, i.e., situations in which allocated memory becomes inaccessible. This can occur in applications that manipulate objects of derived type with pointer components.
Most memory leakage can be avoided if it is possible to specify that pointers be created with an initial status of disassociated.
This standard provides a new intrinsic function, NULL, with a single optional argument. NULL allows the initial status of a pointer to be specified as disassociated in declarations, structure constructors, or type definitions.
Several alternatives were considered and rejected for a variety of reasons. Most of these reasons involve the problem of disambiguating references to generic procedures; i.e., when a program invokes a generic procedure, which specific procedure is supposed to be invoked? Completely defining a pointer object before using it does not help with the disambiguation problem. Creating a NULL constant does not provide any way to specify the type and type parameters of the pointer that is returned. A NULL function with a MOLD argument provides these needed capabilities.
This language extension does not completely solve the memory leakage problem; for that, an automatic destructor is needed which would be invoked for local pointers and structures with pointer components when the procedure in which they are created terminates. Such a facility is not included in this standard; it could be provided automatically by a processor that strove to conserve allocatable memory.
Automatic pointer destructors were not included in this standard because the consequences of inaccessible pointers are not as serious as they are with allocatable arrays which become inaccessible. If a local, unSAVEd pointer is not deallocated and the program exits the procedure in which it is defined, the storage is not recoverable but the pointer is reusable.
For reasons of determinacy and portability, an object for which default initialisation is specified is not allowed to appear in a DATA statement. In traditional implementations, a compiler passes initialisation information for non-dynamic variables to a loader, which is frequently designed to handle object code from several Different languages. It would be difficult to guarantee that initialisation in a DATA statement would override the default initialisation specified in a type definition.