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

[basic.lookup.unqual] Clarify conversion-function-id components lookup #5191

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

languagelawyer
Copy link
Contributor

What does looked up in the same fashion as the \grammarterm{conversion-function-id} mean when the \grammarterm{conversion-function-id} is not looked up? Like in declarations.

struct S
{
  using T = int;
  operator T(); // `operator T` is not looked up. What does it mean for T?
};

S::operator T() // same here
{ return {}; }

@jensmaurer
Copy link
Member

@opensdh, your territory.

source/basic.tex Outdated Show resolved Hide resolved
@tkoeppe
Copy link
Contributor

tkoeppe commented Feb 21, 2022

@opensdh: What's your verdict -- is this an improvement, and, importantly, is this still editorial?

If $T$ appears in a \grammarterm{conversion-function-id} that is a qualified name
whose lookup context\iref{basic.lookup.qual} is a class $S$,
lookup for $U$ performs a search in the scope associated with $S$;
if that lookup finds nothing, $U$ undergoes unqualified name lookup.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be clearer to say "[…]; otherwise, or if that lookup finds nothing, […]". It's true that the general "Unless otherwise specified" from the previous paragraph ought to apply, but it tends to sound like the alternative is that the name is not looked up at all.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's true that the general "Unless otherwise specified" from the previous paragraph ought to apply, but it tends to sound like the alternative is that the name is not looked up at all.

To me, the previous paragraph clearly applies to unqualified \grammarterm{conversion-function-id} :/
May I not apply the proposed change, please?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This paragraph is about an unqualified U, looked up separately from the conversion-function-id that contains it. I want to avoid the (nonsensical) suggestion that, if T does not appear in the given context, U is not looked up at all.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This paragraph is about an unqualified U, looked up separately from the conversion-function-id that contains it.

Yeah, right, but whatever, the previous paragraph applies to other unqualified names (which are not mentioned in this paragraphs) (and in any other paragraphs-exceptions).

I want to avoid the (nonsensical) suggestion that, if T does not appear in the given context, U is not looked up at all.

I don't see how is it possible. I mean, not only the previous paragraph, but also the previous sentence suggest that such U s are looked up:

Lookup for an unqualified name U that is ... of a conversion-type-id T considers only names that ... If T appears in a conversion-function-id ...

If U is not looked up when T doesn't appear in conversion-function-id, there is no reason these sentences are in this and not the opposite order

Copy link
Contributor

@opensdh opensdh Feb 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't insist on a change; it just strikes me as a trip hazard for the reader to say "If X, then Y; if Y does nothing, Z." and have Z also happen when X doesn't obtain.

@opensdh
Copy link
Contributor

opensdh commented Feb 22, 2022

I didn't know I issued verdicts. I think this is definitely an improvement (and I made my one further comment about it); it's certainly not strictly editorial, although one could argue that it merely stipulates the obvious thing in a place where the existing text does not specify any behavior. It might fall into the "CWG glances at a merge request during a teleconference" category.

@tkoeppe
Copy link
Contributor

tkoeppe commented Feb 22, 2022

Thanks, that's precisely what I needed to hear! @jensmaurer: could you kindly ask the CWG chair to clear this proposed change with his people?

@tkoeppe tkoeppe added the cwg Issue must be reviewed by CWG. label Feb 22, 2022
@tkoeppe tkoeppe removed their assignment Feb 22, 2022
@jensmaurer
Copy link
Member

jensmaurer commented Feb 22, 2022

There is still a request for further adjustment by @opensdh. Will forward to the CWG chair after that is fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changes requested Changes to the wording or approach have been requested and not yet applied. cwg Issue must be reviewed by CWG.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants