[J3] Templates Papers Ready for Vote

[Van Snyder]

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.

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"?

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.

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

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

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.

Does Ctt40 actually apply to Rtt25, not Rtt24?

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

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

Some examples of prohibited usage would improve tt.5.3

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.

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.

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

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

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?

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?

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.

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.

The final "constant" in Ctt18 should be "constants".

The final "procedure" in Ctt22 should be "procedures".

Is REQUIREMENT needed in 5.3.2 Statement order?

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

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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20251103/9b11e02c/attachment.htm>