What entities should be allowed to be templated?

[tclune]

I am attempting to divert a discussion that is currently flowing on the J3 mailing list. Moving that discussion to here may broaden the audience as well as make it easier to split into more specific issues, use hyper-refs, and make rendering code a bit cleaner. I am not going to try to post that extensive discussion here, so some repeat may be necessary.

The broad concern is just which entities should be able to be templated with the primary candidates being derived types, procedures, and modules. A strong argument can be (and has been) made that templated modules (ala parameterized modules of past J3 papers) is sufficient, obviating the need for either of the other cases. A counter-argument is that there is value in being able to support more fine-grained placement of template parameters on types and procedures. As Van Snyder and others have pointed out, one must be careful to avoid the pitfalls of Fortran PDT's where type-bound procedures don't really work in a useful fashion with type parameters.

Several intermediate approaches have been suggested in the J3 mailing thread, but rather than attempting to do justice to them in this first post, I'm hoping the proponents can come back here and post their suggestions and relevant code examples. (I've not done my homework yet, and would invariably get something wrong and only add to the confusion. If the needed follow-ups don't happen I will go back and do my best to accurately summarize the options.)

[wclodius2]

I think this topic is mis-titled. Given the contents of your post, I would title this "What should be allowed to be templated?". Assuming that topic I would "template" modules and procedures. I would not explicitly template derived types as that has the potential of creating a derived type that is not consistent with its procedures. Consistency of a derived type with its procedures, as is required for containers, is currently provided by modules, and I would not change that for templates. A module's template parameters would implicitly parameterize included derived types and procedures that use the template parameters without overriding them via scope rules.

The parameters of a templated procedure would normally be independent of the parameters of any other templated procedure. If procedures need to be cross consistent in parameters, then the parameters would normally be the parameters of the enclosing templated module. If any procedures need to be cross consistent, this will normally be so pervasive, that it will be obvious from the module's initial definition, that the associated parameters will need to be in the module's template parameters. If any included procedures are also templated, then the module's template parameters would be substituted, before the final instantiation, using the parameters of the procedure's template. We would probably want to forbid an included templated procedure from having parameters with the same name as any parameter of an enclosing templated module.

I probably would not allow including modules in the scope of another module as:

1. Parameterizing a module so that enclosed procedure(s) can be parameterized seems too indirect for me;
2. It would lead to even higher levels of indentation; and
3. Keeping track of scopes would be more complicated.

But I could easily change my mind on this.

[tclune]

Regarding the title: fair enough. In hindsight, my original title could have been misconstrued in a rather rude way were anyone so inclined. Changed.