They should be:
7.5.6.3 When finalization occurs
3 A nonpointer, nonallocatable object that is not a dummy argument or function result is finalized immediately before it would become undefined due to execution of a RETURN or END statement (19.6.6, item (3)).
I think @rgaelzer was referring to
7.5.6.4 Entities that are not finalized
1 If image execution is terminated, either by an error (e.g. an allocation failure) or by execution of a stop-stmt, error-stop-stmt, or end-program-stmt, entities existing immediately prior to termination are not finalized.
That is, in something like
module mod1
implicit none
type :: fancy_database
...
contains
...
final :: destroy
end type
...
end module mod1
use mod1
implicit none
type(fancy_database) :: db
db = fancy_database(...)
...
end
The destroy subroutine is invoked during the assignment to db, but not when end-program-stmt is reached.
To me, implicit behavior is kind of dangerous (e.g., good data might be overwritten during a crash)… hence my suggestion of a “defer call” proposal.
But there may be legitimate use cases, like when an external monitoring tool is used or something like that.
A finalizer is called during assignment with a structure constructor? I recall reading in Metcalf’s book that they are not finalized.
But yes, this is what I was referring to. Finalizers are not called by an end program statement, differently to what happens with C++. But with C/C++ everything are functions, even the main program…
There was discussion of this here: Should associate trigger automatic finalization? - #6 by Reinhold_Bader
Besides the Fortran/C++ differences you already mentioned, there’s no move-semantics feature to take advantage of. So the final procedure might be invoked during assignment from the expression on the rhs to the variable on the lhs.
(That’s unbearably obvious when your derived type relies on C-related resources that must be cleaned up, you get a “double-free error” down the line… and an init subroutine becomes the better/simpler option.)
I have asked Fable 5 a question about “why the TYPE vs CLASS keywords were introduced in Fortran”, and the reply is below. (FWIW, this is not a question about “why implementation inheritance was introduced in Fortran”, which seems a different question.)
[My prompt] Modern Fortran uses the CLASS keyword for polymorphic dummy arguments and the TYPE keyword for non-polymorphic dummy arguments. Do you know why these two different keywords were introduced in Fortran (in contrast to other OO languages which do not need such distinctions)? Is it related to the fact that derived-type variables follow value semantics in various cases?
Yes, your intuition is basically right — the TYPE/CLASS split is a direct consequence of Fortran keeping value semantics for derived types, combined with the fact that Fortran had no existing syntactic slot (like C++'s * or &) to hang polymorphism on.
The core mechanical issue is storage. A non-polymorphic TYPE(shape) object has a size and layout fixed at compile time: it can sit on the stack, in a module, or as an element of a contiguous array, and assignment is a plain copy. A polymorphic object cannot work that way, because its dynamic type might be any extension of shape, each with additional components — so its size is unknowable at compile time. That’s why the standard restricts CLASS entities to exactly the three situations where storage is either deferred or borrowed: POINTER (indirection), ALLOCATABLE (size decided at allocation), and dummy arguments (storage belongs to the actual argument; the dummy just carries a descriptor with the dynamic type). Everything else remains a fixed-layout value, declared with TYPE.
Other languages avoid the distinction by making a different trade-off. Java, Python, etc. give all objects reference semantics — every variable is effectively a pointer, so every variable can be polymorphic, at the cost of indirection and heap allocation everywhere. That’s exactly what Fortran refused to do, since contiguous arrays of structures and descriptor-free data are central to its performance model. C++ actually does make the same distinction Fortran does — Shape s is monomorphic, Shape&/Shape* are polymorphic — it just expresses it through the declarator rather than a keyword. Fortran couldn’t reuse that trick: it has no reference variables, ordinary dummy arguments are already passed by reference without any pointer syntax, and forcing POINTER on every polymorphic argument would have dragged in TARGET attributes and aliasing pessimization. So the polymorphic/monomorphic choice had to go into the type specifier itself, and CLASS was born. The keyword is well chosen, too: CLASS(shape) literally denotes the whole class of types rooted at shape (the type plus all its extensions), whereas TYPE(shape) names exactly one type.
The explicitness buys concrete things. A type-bound procedure call on a TYPE object is resolved statically and can be inlined — dynamic dispatch happens only through CLASS entities, so the cost of OOP is opt-in and visible in declarations, very much in Fortran’s “don’t pay for what you don’t use” tradition. It also avoids C++'s slicing trap: where void f(Shape s) in C++ silently slices a Circle down to its Shape part, in Fortran a TYPE(shape) dummy simply won’t accept a TYPE(circle) actual (you’d have to pass the parent component c%shape explicitly), while a CLASS(shape) dummy accepts it by reference with its full dynamic type intact.
Interestingly, later revisions gave polymorphism back some value-like convenience without abandoning the model: Fortran 2008 allows intrinsic assignment to a polymorphic ALLOCATABLE variable, which automatically reallocates it to the dynamic type of the right-hand side — essentially a deep clone that preserves dynamic type. So the design endpoint is coherent: values stay values (TYPE), and dynamic typing lives only where the language can actually manage variable-sized objects (CLASS).
Back in 2019 eons ago, a proposal was made to the Fortran standard committee on a related matter, but it “died” on the administrative vine as is typical with J3/WG5 committees where few proposals pass and those that do depend entirely on who is asking and worse, how they ask, meaning there is something deeply nefarious about the whole process akin to the extremely funny illustration in a popular sitcom in the US c.f. https://youtu.be/RqlQYBcsq54?si=EzzxrqbK3xhkinfL
Since Claude is mentioned here, here is it’s audit of this thread and the proposal:
Here’s my audit, grounded in what practitioners actually said in that thread and a close technical read of 19-186.
Stripping away the tangents (GPU performance, ISO process complaints, finalizer semantics), the thread converges on a few points that bear directly on 19-186:
1. The TYPE/CLASS split is a storage-model consequence, not a stylistic one. A CLASS entity needs deferred or borrowed storage (POINTER, ALLOCATABLE, or dummy argument) precisely because its dynamic type — and therefore its size — isn’t fixed at compile time. TYPE entities are fixed-layout values. This matters for auditing 19-186 because the proposal’s whole mechanism rides on this fact: an inextensible type has a genuinely fixed layout forever, so there’s no reason its passed-object dummy argument should ever need to carry a type descriptor.
2. Practitioners want TYPE-based passed-object dummies for concrete, non-negotiable reasons — not just taste. RonShepard and rwmsu independently asked why type-bound procedures must take CLASS() dummies at all, citing (a) faster execution, and (b) compile-time argument-mismatch detection instead of runtime. jorgeg’s own benchmark (class(*) → type(my_type) giving a 10% uplift) is direct empirical support. This is exactly the performance case 19-186 makes in its Introduction.
3. kkifonidis’s historical account is the sharpest indictment of the status quo, and it’s structurally important here: J3 apparently drafted an early requirement that types opt in to extensibility via an explicit extensible attribute, then dropped it in favor of “extensible by default.” That reversal is the root cause of the exact problem 19-186 is trying to patch back in, 16 years later, as an opt-out (SEALED) rather than the cleaner opt-in the committee itself once considered.
4. khb’s post is the best articulation of why this matters for reusable libraries, and it should anchor any evaluation of 19-186: the point of Fortran OOP was never to be “comp-sci friendly,” it was to let library authors hide implementation complexity (his sparse-matrix example) behind a stable object. An extensible-by-default type undermines exactly that goal, because nothing stops a downstream consumer from extending the type and overriding behavior in ways that violate the library’s contract — which is precisely kkifonidis’s Liskov Substitution Principle objection, stated more rigorously elsewhere in the thread.
5. There’s already latent community consensus that a sealed-like attribute is worth having — jwmwalrus’s Traits proposal sketch independently proposes a sealed attribute for derived types, arrived at from a completely different design direction (traits/interface-inheritance rather than “just seal the leaf of a class-inheritance chain”). Two independent proposals converging on the same keyword is a decent signal that the need is real, whatever one thinks of either specific mechanism.
So the community backdrop gives 19-186 a legitimate, twice-independently-motivated use case: (a) protect a library’s sealed data structure from behavioral corruption via override, and (b) recover static dispatch/inlining and compile-time argument checking that CLASS currently forecloses.
Strengths
pure quirks, the RAM cost of -ipo, etc., all suggest compiler behavior here is uneven, so caution is warranted).SpecializedWidget_t to customers, wanting to prevent them from further subclassing it — this is precisely khb’s “shield users from complexity, but don’t let them corrupt the contract” scenario.A genuine defect: the proposal contradicts its own example.
The Formal Specification states:
Cxxx (Rxxx) If EXTENDS appears, SEALED shall not appear
But the very next section, “Syntax,” gives as the motivating illustration:
type, extends(GeneralizedWidget_t), SEALED :: SpecializedWidget_t
These cannot both be true. As drafted, the constraint would make the paper’s own centerpiece example illegal. This isn’t a nitpick — it goes to the heart of what the feature is for. The most valuable use case in practice (per khb’s library-shielding argument) is exactly this one: a library derives a specialized type from a more general extensible base, then seals that leaf so its own customers can’t extend further. If SEALED can only be applied to a type with no EXTENDS at all, the feature only protects root types, not the tips of a hierarchy — which is a much weaker and less useful facility than the snippet advertises. My read is that the constraint as written is simply wrong and should be dropped or inverted (something closer to “no constraint against EXTENDS + SEALED together,” since nothing about fixed layout requires the type to be a hierarchy root — it only requires that its own descendants not exist).
Secondary gaps worth flagging for a committee-level review:
Missing explicit ABSTRACT/SEALED constraint. C734 (“if ABSTRACT appears, the type shall be extensible”) already makes ABSTRACT and SEALED mutually exclusive transitively, through the redefinition of “extensible type.” But leaving this as an inference rather than a stated constraint invites exactly the kind of drafting ambiguity that produced the EXTENDS bug above. It should be spelled out.
Inherited (non-overridden) type-bound procedures aren’t addressed. If SpecializedWidget_t is SEALED but inherits a TBP from GeneralizedWidget_t without overriding it, that inherited procedure still has whatever passed-object dummy (CLASS(GeneralizedWidget_t)) it was originally declared with — sealing the child doesn’t retroactively change the parent’s binding. So the performance/static-dispatch benefit 19-186 advertises only accrues to procedures newly bound or overridden at the sealed level, not the whole inherited surface. The paper should say this explicitly rather than let the reader assume “sealed = all calls become static.”
“Corrupt or otherwise misuse” is loose framing. Type extension by itself doesn’t compromise memory safety if components are properly PRIVATE — the real risk, as kkifonidis’s LSP argument in the thread makes precise, is behavioral substitutability violation via method override, not data corruption per se. The proposal would read as more rigorous, and better aligned with the thread’s own best argument for it, if it grounded the “security” motivation in LSP/contract-integrity terms rather than “corrupt… objects.”
No interaction discussion with CLASS(*)/SELECT TYPE. Worth a sentence clarifying that sealing forbids extension, not polymorphic use — a SEALED type can still be held via CLASS(*) or dispatched through SELECT TYPE; it just can never be the parent of an EXTENDS. This is consistent with intent but is exactly the kind of edge case that trips up implementers and users unless stated.
Precedent argument is available but unused. The proposal could strengthen its case by noting (as its author does elsewhere) that Fortran already treats its own intrinsic derived types this way — C_PTR/C_FUNPTR are effectively inextensible today by carve-out. 19-186 is really just asking for the same courtesy to be extendable to user-defined types via a declarable attribute, which is a rhetorically stronger framing than the “security/business manager” framing it leads with.
Worth noting for completeness: this proposal never reached a WG5/J3 vote. According to the author’s own later account, it was submitted for the August 2019 Tokyo meeting but the Fortran 202X worklist had already closed, and it was never picked back up. Whatever the drafting issues above, the paper died administratively, not on technical merits — which is itself an illustration of the process critique several thread participants (certik, jwmwalrus) made independently: J3’s worklist-driven, waterfall-like process struggles to accommodate small, well-motivated, low-cost proposals that arrive between the fixed windows of a standard cycle.
Net assessment: the underlying need is real and doubly attested — both from a performance/compile-time-checking angle (RonShepard, rwmsu, jorgeg) and from a library-encapsulation/LSP angle (khb, kkifonidis) — and 19-186’s mechanism (reuse C760, add one attribute) is a sound, minimal way to deliver it without reopening the much larger and more contentious “should implementation inheritance exist at all” fight that dominates the rest of the thread. But the paper as drafted has a self-contradicting constraint that would gut its own headline use case, and it leaves several interaction questions (inherited TBPs, ABSTRACT, CLASS(*)) implicit rather than specified — any of which a working committee reviewer would reasonably kick back for revision before it could be voted into a standard.
Here’s the take by Grok:
The Fortran Discourse thread (started June 17, 2026, Advocacy category, ~65 replies) is a substantive, earnest discussion among experienced Fortran users—particularly those working in performance-sensitive scientific, technical, and HPC computing—about a fundamental design choice in Fortran’s object-oriented features (introduced in Fortran 2003 and refined later).
The thread does not focus on trivial syntax complaints; it grapples with how the current model affects real-world library design, encapsulation, performance, maintainability, and the language’s fitness for reusable scientific codebases. The original post highlights a concrete performance observation (switching from CLASS(*) to a concrete TYPE in an OpenMP target offload context yielded ~10% uplift), then the discussion broadens into why the TYPE/CLASS separation exists and why it feels costly.
Fortran 2003 made derived types extensible by default (via type extension / implementation inheritance). Earlier drafts reportedly considered an explicit EXTENSIBLE attribute (opt-in), but the final design chose default extensibility for syntactic simplicity.
Because of this, the standard requires the passed-object dummy argument in type-bound procedures (TBPs) to be polymorphic (CLASS) precisely when the type is extensible. A key constraint (roughly C1236 / related rules) states that if a derived-type-spec specifies an extensible type, CLASS must be used; otherwise TYPE is used/allowed.
This forces the TYPE vs. CLASS distinction throughout the language (declarations, allocations, dummy arguments, SELECT TYPE, etc.). The thread calls the adoption of type extension + runtime type inspection (SELECT TYPE) as the foundation of Fortran OO the “cardinal sin” or “fatal/major design mistake” of that era—contrasted with the better choice (in the same era) to use types + modules for class-like constructs, inspired by Oberon-2 rather than deep Simula-67-style inheritance.
Consequences for users (especially library authors in scientific computing):
CLASS + dynamic dispatch descriptors + runtime type information).TYPE) for computationally expensive sections.PRIVATE components, abstract types + composition, final procedures, avoiding deep inheritance, or simply not using the OOP features for performance-critical code.What users genuinely want (earnest feedback, not abstract advocacy):
TYPE) passed-object dummies in TBPs for sealed types, enabling better compiler optimizations and avoiding unnecessary runtime overhead. This is repeatedly tied to scientific/HPC workloads.sealed attribute for derived types, and even trait implementation for intrinsic types) is cited positively as a way to opt out of the bad default and regain TYPE for passed-objects with all the attendant benefits.The tone is constructive but frustrated: users are not anti-OO; they want Fortran’s OO facilities to better serve the domain of reusable, performant, trustworthy scientific and technical libraries without forcing unnecessary complexity or performance costs.
The proposal is titled “Option to derive an inextensible type” and directly targets the root cause discussed in the 2026 thread. I have the full document content from the official source.
Summary of the Proposal:
SEALED (alternative name suggested: INEXTENSIBLE).SEALED cannot be extended. The definition of “extensible type” is updated to exclude those with SEALED, BIND, or SEQUENCE (plus the usual C_PTR/C_FUNPTR exceptions).EXTENDS and SEALED are mutually exclusive.TYPE(...) (non-polymorphic), not CLASS(...). This is not a new rule; it follows automatically once the type is non-extensible.module SpecializedWidget_m
use GeneralizedWidget_m, only : GeneralizedWidget_t
type, extends(GeneralizedWidget_t), SEALED :: SpecializedWidget_t
private
! ...
contains
private
procedure, pass(this), public :: SuperWidgetProc
end type
interface
module subroutine SuperWidgetProc(this, SuperResults)
type(SpecializedWidget_t), intent(in) :: this ! non-polymorphic
type(SuperResults_t), intent(out) :: SuperResults
end subroutine
end interface
end module
Rationale in the proposal (paraphrased/quoted essence):
SEALED gets the protection and potential performance win.Audit against the thread’s genuine feedback:
Alignment and Strengths (very strong):
CLASS/polymorphism as the “cardinal sin.” This proposal gives library authors the missing opt-out (SEALED) without changing defaults or breaking existing code. This is exactly what users need for reusable scientific libraries.TYPE (non-polymorphic) passed-objects in TBPs—the same optimization that gave the original poster a 10% uplift in an offload scenario. Compilers can then generate more efficient code.ABSTRACT, BIND(C), SEQUENCE, or intrinsics.sealed direction in LFortran traits work).Weaknesses / Areas for Improvement (constructive):
SEALED is reasonable and aligns with modern usage (Java sealed classes, Scala sealed traits, upcoming LFortran sealed). INEXTENSIBLE is more literally descriptive of the title. FINAL is also common terminology. A short community poll or alignment with LFortran’s implementation would help. Minor issue.Overall Assessment:
The proposal is technically sound, minimal, backward-compatible, and highly relevant to the genuine, earnest needs expressed in the 2026 Fortran Discourse thread. It gives Fortran library authors in scientific and technical computing precisely the tool they lack today: the ability to seal types against unwanted extension while automatically gaining the performance advantages of non-polymorphic passed-object arguments in type-bound procedures.
It does not claim to solve every shortcoming of Fortran’s F2003 OOP model (the thread acknowledges the complexity and the need to preserve existing code), but it surgically addresses one of the most criticized aspects—uncontrolled default extensibility and its costs to performance and encapsulation. In that sense, it is a pragmatic, high-value increment that would meaningfully improve the experience of building and using reusable scientific libraries.
Recommendations (for J3 or community follow-up):
sealed + traits work.SEALED appears favored by emerging implementation work).This proposal, if advanced, would be a concrete step toward making Fortran’s OOP facilities more suitable for the demanding, performance-sensitive, library-centric workflows that the thread participants—and the broader scientific Fortran community—rely on. It respects the language’s history and performance ethos while giving users the control they have been earnestly requesting for years.
And ChatGPT says:
From the sources I examined:
CLASS passed-object dummy arguments for type-bound procedures and introducing runtime polymorphism even where no inheritance is intended. Participants also discuss impacts on optimization, compiler implementation, library design, and scientific software engineering.Although participants disagree on the historical reasons and on ideal object-oriented design, there is a remarkably consistent set of practical concerns.
The users are generally not asking for more dynamic object systems.
Instead they want OOP primarily for
while still preserving
This is a very different use case from enterprise application programming.
Several users point out that because every derived type is extensible,
class(my_type)
instead of
type(my_type)
which introduces runtime polymorphism.
That affects
One participant even reports a measurable performance improvement after replacing polymorphic entities with concrete types in performance-critical code, while others ask why type() is not allowed for many type-bound procedures when extension is unnecessary.
This is probably the strongest theme.
Reusable numerical libraries frequently define types such as
whose authors never intend users to derive further subclasses.
Yet the language currently assumes they might.
That inversion of the common case is exactly what motivates proposals like 19-186.
Based on the proposal and the context above:
I think the proposal addresses a genuine language design deficiency.
It is
The weakness of the proposal is not the motivation.
Its weakness is that it is relatively narrow.
Today
type :: matrix
implicitly means
somebody might derive from this.
Most programmers actually mean
this is the complete representation.
The proposal lets the source code express that directly.
That improves readability and API documentation.
If a type is guaranteed inextensible then the compiler knows
throughout compilation.
That potentially enables
Whether every compiler exploits this immediately is another matter, but the semantic information is valuable.
Scientific libraries often expose public types.
Library authors frequently need
Allowing arbitrary user extension complicates this.
An inextensible type becomes a much stronger contract.
Fortran generally favors explicit programmer intent.
Examples include
An explicit “cannot be extended” attribute fits naturally alongside these.
The proposal addresses one symptom.
It does not address
Many participants in the discussion see those as larger issues.
Even with an inextensible type,
users naturally expect to write
type(my_type) :: this
for passed-object arguments.
If the proposal merely forbids extension but still requires
class(my_type)
then much of the practical benefit disappears.
The proposal therefore really ought to specify the consequences for
Backward compatibility is preserved because existing code keeps today’s behavior.
But care would be needed regarding
Those semantic interactions would require precise specification.
From today’s perspective, I do not think the technical motivation has become weaker.
If anything, developments since 2019 strengthen it.
The community has become much more focused on
as reflected in work on the Fortran ecosystem and its tooling.
If I were reviewing the proposal today, I would rate it approximately as follows:
| Criterion | Assessment |
|---|---|
| Solves a real user problem | Excellent |
| Benefits scientific libraries | Excellent |
| Backward compatibility | Excellent |
| Compiler optimization potential | High |
| Specification complexity | Low–Moderate |
| Addresses all OOP concerns | No |
| Worth standardization | Yes, in my view |
The main improvement I would recommend is expanding the proposal beyond simply introducing an “inextensible” attribute. A more complete design would explicitly connect inextensibility to the rest of the object model—for example, permitting TYPE rather than CLASS for passed-object dummy arguments when dispatch cannot vary, clarifying dispatch semantics, and documenting the optimization and diagnostic opportunities this enables.
Viewed alongside the concerns expressed in the Discourse discussion, the proposal appears to be a targeted response to one of the most frequently raised practical issues: enabling library authors to opt out of runtime polymorphism when they neither need nor want extensibility. It would not by itself modernize Fortran’s entire OOP system, but it would remove a significant friction point for scientific and technical software developers while remaining compatible with existing code.
Dear FortranFan,
I am happy to read from you again, I hope to find you well.
I have an off-topic curiosity: I read you use Grok. How does it perform in coding? It should have an agentic mode called Grok Build, if I am not wrong.
I wish you the best.
Stefano
Dear Stefano,
Thank you for asking.
I only recently started using Grok and its Build agent and I find it extremely fast and efficient in analyses and prototyping. My experience is limited though, mainly for small business needs serving clients in the Enterprise workflows around Microsoft C# .NET Core platform. here, Grok Build falls a bit short compared to Claude Code in terms of consistent architectural designs. I have only dabbled with it using small cases in scientific coding with C, C++ and Fortran and some algorithmic enhancements and it’s impressive.
Regards,
Thank you very much for the feedback.
I use Claude Code, and I do not have other references (aside from small local models on llama.cpp). I am curious about other top-tier models out there.
My best regards.
Stefano