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

"Template template arguments" contributing to ADL? #2820

Closed

Conversation

Quuxplusone
Copy link
Contributor

Discussed on Slack with @K-ballo and we decided we have no idea what the parenthesized wording here is supposed to mean; therefore I wildly propose that we just strike it. @zygoloid, please help prove me wrong!

Furthermore, I claim with stronger confidence that the phrase "the templates used as template template arguments" is redundant, given the following phrases "the namespaces of which any template template arguments are members; and the classes of which any member templates used as template template arguments are members." I don't think it is meaningful for a template itself to be an associated entity.

K-ballo did find this completely crazy example which is supported by GCC (but not Clang, ICC, or MSVC):

// https://godbolt.org/z/zw8WAs
namespace A {
  template <class>
  void otherfun() {}
}

namespace B {
  class T;
  void call(void(*)()) {}
}

int main() {
    call(A::otherfun<B::T>);
}

Here, the type of A::otherfun<B::T> is unknown (because it's an overload set); but GCC believes that B is an associated namespace (and A is not an associated namespace), presumably somewhat on the basis of the extremely confusing wording touched by this PR.

@Quuxplusone
Copy link
Contributor Author

Update: The "completely crazy example" is actually 100% legit and GCC is right to accept it, according to http://eel.is/c++draft/basic.lookup.argdep#2.sentence-8

In addition, if the argument is the name or address of a set of overloaded functions and/or function templates, [...] if the aforementioned set of overloaded functions is named with a template-id, its associated entities and namespaces also include those of its type template-arguments and its template template-arguments.

So that example is probably not relevant to this PR at all.

@CaseyCarter
Copy link
Contributor

I don't think it is meaningful for a template itself to be an associated entity.

Does 4.4 not make it so? Certainly 4.3 would if "declared in classes" were corrected to "declared in classes or class templates".

@@ -1692,8 +1692,7 @@
to be considered.
The sets of namespaces and entities
are determined entirely by
the types of the function arguments
(and the namespace of any template template argument).
the types of the function arguments.
Copy link
Contributor

Choose a reason for hiding this comment

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

If we're killing words here, take the next sentence as well. The moons of Saturn also don't contribute to the sets of associated namespaces and entities, but we don't need to proclaim that fact normatively.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The parenthetical was nonsensical; the next sentence is merely redundant. I wouldn't object to removing the next sentence, but maybe I should open a completely orthogonal PR for that.

@zygoloid
Copy link
Member

This wording was added by P1103R3 and made necessary by changes in that same paper. See this wording in p4:

"Any declaration D in N that is in the interface of a named module M (10.2) is visible if there is an
associated entity attached to M with the same innermost enclosing non-inline namespace as D."

Passing a template exported from a module M as a template template argument makes the interface of module M visible to the lookup, and that only happens because we now consider template template arguments to introduce associated entities.

@zygoloid zygoloid closed this Jun 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants