[J3] Templates Papers Ready for Vote

[Brad Richardson]

Hey all,

In addressing Van's comments we now have new revisions uploaded and ready for vote on Wednesday, specifically

25-175r4
25-204r1

Additional responses interspersed below.

On Monday, November 3rd, 2025 at 8:21 PM, Van Snyder via J3 <j3 at mailman.j3-fortran.org> wrote:

> On Mon, 2025-11-03 at 20:00 +0000, Brad Richardson via J3 wrote:
>
>> Hey all,
>>
>> Papers 25-175r3 and 25-204 have been uploaded and will be for vote at the Nov. 12th plenary. 25-175r3 is the miscellaneous edits, and 25-204 is the final, combined edits paper for Templates, which is just a simple combination of the previous edits papers.
>>
>> Regards,
>> Brad Richardson
>
> I should have been paying closer attention to the development of templates. Here are my better-late-than-never comments on 25-204. Maybe some are nonsense because I haven't been paying sufficient attention. Those that are nonsense might result from confusion that could be addressed by different wording.
>
> In Ctt38 there either ought not be a comma before "or", or not after "therein". But of course the editor has the final choice.

Agreed, corrected.

> Ctt05 says one of ABSTRACT or EXTENSIBLE shall appear, but neither one appears in the examples in NOTE 2 from 25-135r2. This is OK, but confusing, because <deferred-type-attr-list> is optional in Rtt04. The constraint might be clearer as "ABSTRACT and EXTENSIBLE shall not both appear"?

Agreed. Fixed.

> Thomas Jefferson advised "never use two words where one will do." NOTE 1 from 25-136r2 could be simplified to "A deferred type cannot be extended. The term "extensible" implies a restriction on the associated instantiation argument.

Agreed. Fixed.

> Might it be possible to allow variables of deferred type to be coarrays by imposing a constraint on the instantiation argument?

This is probably feasible, but we'll tackle it in the next revision of the standard.

> Is there a reason to prohibit real or complex deferred constants?

This was to avoid problems with inconsistency between compilers regarding whether two instantiations are the same or not if different (but potentially equivalent) expressions are used. i.e. INSTANTIATE TMPL(1.0 / 3.0) vs INSTANTIATE TMPL(3.0 / 9.0). We plan on trying to expand what types can be deferred constants in the next revision of the standard.

> Is an IMPORT statement needed in NOTE 2 in tt.4.1.4, or does a DEFERRED INTERFACE access its containing scoping scoping unit by host association? The edit for 138:7 appears to say it's not needed. I prefer the latter, and preferred it for ordinary interface bodies in 1986. I have still not seen a satisfactory explanation for the decision to disallow it.

No, deferred interface bodies have host association by default.

> Does Ctt40 actually apply to Rtt25, not Rtt24?

We applied this constraint to Rtt25 and Rtt26 with some improved wording.

> The two paragraphs after Ctt42 is confusing because the ONLY option and <rename> do not appear until several paragraphs later.

The ONLY and <rename> options already exist as syntax in the standard for USE statements, and appear in the syntax for Rtt25, so we're not sure what the confusion is here.

> I don't understand the NOTE in tt.5.2. Does this prohibit recursive templated procedures?

Effectively yes. One can have recursive procedures in regular templates if needed. We could potentially figure out some way to enable recursive templated procedures in the next revision of the standard.

> Some examples of prohibited usage would improve tt.5.3

We added an example

> I don't object to the flexibility allowed by tt.5.4. Would it cause implementers undue trouble? Users could achieve the same effect if one were required to instantiate once and then access the instance as a local instance or by use or host association.

With "distributed development" becoming more popular we want to be able to avoid the requirement to have some "canonical" instantiation of a template defined somewhere. There are some use cases where this couldn't be accomplished as well. My understanding is that C++ has figured out how to deal with this problem in any case.

> Are the interface bodies in the example in NOTE 2 in tt.5.4 required to have IMPORT (or USE) statements? The edit for 138:7 appears to say it's not needed.

They are needed in the first interface block. Good catch.

> Ctt47+ isn't defective, but would benefit from a comma before "or"

Fair enough. Added.

> Should Ctt49 and Ctt50 say "if and only if"?

No, they are not that restrictive. An extensible type can be an instantiation argument for a deferred type that does not have the EXTENSIBLE attribute, and a non-abstract type can be a instantiation argument for a deferred argument that has the ABSTRACT attribute.

> NOTE 1 in tt.5.4.2 says that Ctt51 ensures that instrinsic assignment is available for variables of deferred type. Chould Ctt51 be restricted to EXTENSIBLE or ABSTRACT types? Or would this allow a template that fails at instantiation time, but that failure could have been detected before instantiation?

No, because derived types can still be instantiation arguments for deferred arguments that don't have the EXTENSIBLE or ABSTRACT attributes.

> Ctt54 appears to require that the corresponding deferred constant has a type and kind type parameter. Should it refer to the instantiated type and kind type parameter of the deferred constant?

Yes, good catch. We've amended this constraint to catch this, along with an example as an editorial comment.

> Ctt58 appears to have been influenced byprocedure argument and/or procedure pointer association. I don't see a reason to prohibit intrinsic procedures that match the interface in the template.

> Ctt61 appears to be unnecessary and perhaps harmful. There is a remark that it is a disambiguating constraint. It would be useful to explain the ambiguity that would result without it.
>
> Ctt62 appears to contradict Ctt58.

We think the above comments are based on a misunderstanding. We have not prohibited intrinsic procedures from being instantiation arguments. They are inherently <generic-spec>, and thus not a <procedure-name>, so constraints Ctt58 and Ctt59 are not applicable to them, and Ctt62 is not contradictory.

> Does the INTERFACE in NOTE 3 in tt.7 require an IMPORT statement? The edit for 138:7 appears to say it's not needed.

No, deferred interface bodies do not need IMPORT.

> The final "constant" in Ctt18 should be "constants".
>
> The final "procedure" in Ctt22 should be "procedures".

We think, based on what an analogous statement would be, that the "s" are not appropriate. E.g. "all declarations of i shall be integer".

> Is REQUIREMENT needed in 5.3.2 Statement order?

No, as many of the other constructs/statements do not appear in REQUIREMENT constructs.

> The "not" in C874+ ought to be "neither"

Agreed. Fixed.

> If templates had been cast as parameterized modules (and instances therefore as internal modules), some of the edits around page 129 about "template or module" would not have been necessary. But that's water over the dam.

There were some aspects of parameterized modules that weren't flexible enough, but you can almost think of these templates that way.

> Are the edits for page 136 about the IMPLICIT statement consistent with the recent paper25-192r1 about default implicit typing?

Yes, the two changes are orthogonal. 25-192 is about the default implicit mapping. Templates do not have a default implicit mapping.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20251110/605e7e48/attachment.htm>