Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix term: template parameter -> argument. #304

Closed
wants to merge 1 commit into from

Conversation

lichray
Copy link
Contributor

@lichray lichray commented May 23, 2014

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

@zygoloid
Copy link
Member

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
Copy link
Contributor Author

lichray commented Sep 15, 2014

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
Copy link
Member

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.

@zygoloid zygoloid added the lwg Issue must be reviewed by LWG. label Sep 25, 2014
@lichray
Copy link
Contributor Author

lichray commented Nov 5, 2014

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

@tkoeppe
Copy link
Contributor

tkoeppe commented Dec 3, 2015

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

@tkoeppe
Copy link
Contributor

tkoeppe commented Mar 8, 2016

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

@lichray
Copy link
Contributor Author

lichray commented Mar 8, 2016

Rebased. And I sent a library issue.

@tkoeppe
Copy link
Contributor

tkoeppe commented Mar 23, 2016

@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
Copy link
Contributor Author

lichray commented Mar 23, 2016

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
Copy link
Contributor

tkoeppe commented May 31, 2016

@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
Copy link
Member

zygoloid commented Jun 22, 2016

This is filed as lwg2599.

@zygoloid zygoloid closed this Jun 22, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lwg Issue must be reviewed by LWG.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants