Dear all, possibly silly and pedantic question incoming. Where in a piece of code can I define a derived type? Can they be freely mixed with variable declarations as long as the order is OK (i.e. defined before used)? A quick test and some logic suggests they are just like variables in this sense,…

Yes, these are all R508 specification-construct (in particular, type-declaration-stmt, derived-type-def and type-declaration-stmt again). [image]

Hi @hratcliffe , generally it’s a good practice to define derived types in the specification section of a module. You can also define a type in a program or a procedure, and it can be used within the body and internal procedures. You can even create “hidden” derived types, which to my understanding…

And it’s OK to mix them in the specification section? Like INTEGER :: foo TYPE bar ... END TYPE TYPE(bar) :: charlie

[image] ivanpribec: associate(f => foo()) print *, f%first print *, f%second print *, allocated(f%third) end associate It looks very weird to me, to be able to reference derived type components in a segment which does not have that type declared. IMHO, it should not be allowed. NB. g…

[image] msz59: NB. gfortran (v. 13.2, 14.2) gives ICE on third print line: I submitted a bug a couple weeks ago: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117077 ifort, ifx, flang(-new), and nagfor all accept the example: > nagfor hidden_type.f90 NAG Fortran Compiler Release 7.2(Shin-Ur…

Actually, I have a similar question about the usage like f => foo(), which appeared in several other threads but I still cannot understand what is happening under the hood. For example, does this sentence associate(f => foo()) mean that the symbol f is associated with the result variable of foo() …

A full explanation of how the construct works is given in J3/24-007, section 11.1.3. Here are just a few excerpts. From 11.1.3.1, paragraph 1: The ASSOCIATE construct associates named entities with expressions or variables during the execution of its block. These named construct entities (19.4) a…

[image] ivanpribec: The interpretation document J3/24-007 (section 7.3.2.2, paragraph 2) has this cryptic paragraph about the case when a type is declared within a function: To me, that cryptic paragraph seems to only allow something like: type(foo_type) function foo() result(f) type :: f…

Sorry for quoting only the part about the type definition. The answer how it can be propagated outside is specified in the ASSOCIATE semantics (see my previous post). Note that the function result type (i.e. the type of the evaluated selector) is public, so the associating entity has a known type: …

I think there’s also circumstances where a second definition is considered the same type as long as the content is the same. So in weird enough codes that might still be useful? Two data entities have the same type if they are declared with reference to the same derived-type definition. Data 7 en…

Well, I accept that it works. Still, it seems inconsistent to me, that in type (foo_type) :: var_foo ! error associate (f => foo()) print *, f%first ! ok ! [...] end associate the var_foo declaration is invalid while f in the associate block is legally recognized as type (foo_type)

Derived type definition locations

Help

Topic		Replies	Views
Should we avoid assignment of derived types in robust programs?	34	4333	January 22, 2022
Parameterized derived types and type extensions Help	18	710	September 8, 2025
Derived type declaration in array constructor Help	29	631	July 10, 2025
Define a function/subroutine inside a derived type Help	9	625	October 20, 2021
How to avoid multiple type definitions due to different kinds? Help	17	1727	March 14, 2022

Derived type definition locations

Related topics