Define a function/subroutine inside a derived type

FortranFan · October 20, 2021, 1:57pm

@fortran4r , please see this proposal at GitHub site for background on your question above:

Feature proposal: open to derive an inextensible derived type

opened 07:26PM - 22 Oct 19 UTC

Clause 7

I submitted this paper **[19-186](https://j3-fortran.org/doc/year/19/19-186.txt)…** for the joint WG5/J3 meeting in Tokyo (August 5 - 9, 2019) but the paper was ignored on account of the worklist for Fortran 202X being closed. I don't know how to get it considered now for Fortran 202Y, perhaps various "thumbs up" by readers here might help push its case? Introduction ------------ 18-007r1 states in section 7.5.7.1 Extensible, extended, and abstract types, "A derived type, other than the type C_PTR or C_FUNPTR from the intrinsic module ISO_C_BINDING, that 7 does not have the BIND attribute or the SEQUENCE attribute is an extensible type." An extension type can thus be derived from any other user derived type which does not have the BIND or the SEQUENCE attributes. Consider a user derived type in Fortran that does not have the BIND or the SEQUENCE attributes and which is employed toward calculational needs involving data structures of some complexity in scientific and technical computing, particulary in industry: the allowance per current standard to extend said type is a matter of great concern in terms of security and predictability of computer operations and results, especially to senior software design architects, computational technology leaders, and budget and business managers. The facility in current Fortran standard to be able to extend all derived types except as stated above makes it feasible, at least conceptually, to manipulate the data and states of objects of such types and to corrupt or otherwise misuse them via type extension, either intentionally or unknowingly. It then becomes difficult, if not impossible, to develop technical software involving specialized derived types because it leaves open the possibility of violation of a technical/business understanding across or within teams not to override some type behavior or functionality via type inheritance. This situation hinders the adoption of Fortran in new engineering and/or scientific software projects where the design paradigm of object-orientation is important but where the needs of the projects also include the requirement to encapsulate the business/technical logic using **data structures which are 'sealed'** so that objects of such structures can then be consumed across the program or libraries without concern of easy alteration. In addition to the above-stated use case of added security and reliability of a 'sealed' derived type, it is also expected that a few or all of the processor implementations will be able to provide some performance benefit with the use of bound procedures with such 'sealed' types. This is on account of some or all processors succeeding in providing more efficient code via nonpolymorphic descriptors of the passed-object dummy argument utilized in procedure calls.

Topic		Replies	Views
Type-bound procedures inside a function/subroutine Help	11	1192	January 7, 2022
Derived type definition locations Help	20	571	December 3, 2024
A derived type containing a callback function as a member Help	12	1096	December 4, 2021
I need bind(py)	4	319	November 11, 2025
Simple/effective way to "attach" function to derived type Help	3	641	October 6, 2022

Define a function/subroutine inside a derived type

Related topics