Fix term: template parameter -> argument.

[lichray]

I'm sure this sentence is copy-pasted across the "incomplete type" cases...

[zygoloid]

Please remove the word "actual". I'm also not entirely happy with the "T of X" in "The template argument for T of X may [...]". So, counterproposal: "In an instantiation of X, an incomplete type may be used as the template argument for the template parameter T." This more directly mirrors the wording in [res.on.functions]/2.5.

[lichray]

Let me remove "actual".

The sentence "In an instantiation of X, an incomplete type may be used as the template argument for the template parameter T." looks odd to me. The "instantiation of X" happens after a type being used as the template argument; the cause and effect are reversed.

The original term "instantiating" used in [res.on.functions]/2.5 is very suitable for describing effects, however, it's too timing-sensitive to be used here, IMO. The phrase "when instantiating" implies that the whole statement no longer applies after the instantiation process, which is not true for the exception cases for incomplete types we made in the standard so far.

I'm OK with keeping the current sentence structure.

[zygoloid]

The sentence "In an instantiation of X, an incomplete type may be used as the template argument for the template parameter T." looks odd to me. The "instantiation of X" happens after a type being used as the template argument; the cause and effect are reversed.

To my reading, it's the instantiation that is prohibited, not forming the template-id, so cause and effect are the right way around here. That is:

X<Incomplete> *p;

... is fine for all library components unless otherwise specified, because [res.on.functions]/2.5 only restricts instantiations, not forming specializations. That said, this may not be the intent of LWG here, and I'd like clarification of that intent before we move forward.

The phrase "when instantiating" implies that the whole statement no longer applies after the instantiation process, which is not true for the exception cases for incomplete types we made in the standard so far.

I believe this phrase appears to exist solely to negate the effect of [res.on.function]/2.5, which only applies "when instantiating". If that's not the intent, then I agree that this is too narrow.

[lichray]

OK, I did not understand "instantiation" correctly (nor for now...), but now I think your suggested wording is right.

[tkoeppe]

Do you plan on pursuing this change? @zygoloid: Should this perhaps be a short paper for LWG?

[tkoeppe]

@lichray: 1) are you still interested in this PR? 2) the PR is out of sync and needs to be rebased.

[lichray]

Rebased. And I sent a library issue.

[tkoeppe]

@lichray: I wonder, if this is now an LWG issue, and the issue will result in wording changes, then we'd get the change as part of a motion, right? So can we close this PR?

[lichray]

I can change the commit message to an application of the motion (if there is one) at that time; I pointed the Proposed resolution of the issue to here actually.

[tkoeppe]

@lichray: Hm, I suppose you could do that, but usually motions that come out of meetings will be summarily dealt with after the meeting, so I doubt the editors would at that point look to existing PRs. Consider in particular that there is a limited, short time window post-meeting in which the motions need to be applied, and if the actual motion is different from your current PR, the PR couldn't be used unless you were available for rapid revisions near that time. All told, I imagine that's an unlikely scenario.

[zygoloid]

This is filed as lwg2599.