Example of the template visibility problem

[Richard Smith]

Here's an example of the template visibility problem that John raised in CWG discussion:

module A;

export template<typename X, typename Y, typename Z> void f(X x, Y y, Z z) {

  g(x);

  g(y);

  g(z);

}

module B;

import A;

export struct X {};

export void g(X);

export template<typename Y, typename Z> void f(Y y, Z z) {

  f(X(), y, z);

}

module C;

import A;

export struct Y {};

export void g(Y);

export template<typename Z> void f(Z z) {

  f(Y(), z);

}

// ----

import C;

struct Z {};

int main() {

  f(Z());

}

I think it's clear that this should work. However, the proposed "you do phase 2 lookup in the context of the instantiation" rule would reject it, because module B is not visible there (and also not visible in the context of the template), so ADL would be unable to find "g(X)".

As mentioned in CWG, the way that Clang deals with this is to track a sequence of points of instantiation for each template specialization (if you consider 14.6.4.1 [temp.point]'s "point of instantiation" recursive computation, we effectively track all the points that are visited on the path to the point of instantiation) -- in this case, that includes all three 'f' templates -- and make visible all declarations that are visible at the end of the module unit containing each such point of instantiation.

Note that Clang does not require a declaration to be re-exported in order to be found in this way. That is necessary to permit a case like this:

module X;

import std.utility;

import C;

template<typename T> void f() {

  std::pair<T, Y> p;

}

// ----

import X;

void g() { f<int>(); }

Note that Y is not exported by X, but its definition must be visible in the instantiation of the pair default constructor in order for this code to work.

However, the precise rule to use here will presumably require some discussion -- should module linkage entities be visible? (I think yes) Should internal linkage entities be visible? (... I don't know. But if we permit their use from exported templates defined within the module interface unit at all, I think the answer there must also be yes, or people will be very confused.)

[Gabriel Dos Reis]

Thanks, Richard, for providing an example that checks all the rules in the current specification and that does not give you the outcome you would prefer.

I will write a paper to cover this in the post-Issaquah mailing.

--
You received this message because you are subscribed to the Google Groups "SG2 - Modules" group.
To unsubscribe from this group and stop receiving emails from it, send an email to modules+u...@isocpp.org.
To post to this group, send email to mod...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/modules/.

[Richard Smith]

On 11 November 2016 at 10:33, Richard Smith <richar...@google.com> wrote:

Here's an example of the template visibility problem that John raised in CWG discussion:

module A;

export template<typename X, typename Y, typename Z> void f(X x, Y y, Z z) {

  g(x);

  g(y);

  g(z);

}

module B;

import A;

export struct X {};

export void g(X);

export template<typename Y, typename Z> void f(Y y, Z z) {

  f(X(), y, z);

}

module C;

import A;

Herb pointed out off-line that there's a typo here: this should say "import B;". Sorry about that!

[Richard Smith]

On 14 Nov 2016 9:34 am, "Jonathan Caves" <Jonatha...@microsoft.com> wrote:

Is there a declaration missing from this example? Should there be a:

 

void g(Z);

 

in the code that imports C?

Yes, there should be. Sorry, this example was written up in a hurry :(

Thanks

JonCaves

 

From: Core [mailto:core-bounces@lists.isocpp.org] On Behalf Of Richard Smith

Sent: Friday, November 11, 2016 10:46 AM

To: C++ Core Language Working Group <co...@lists.isocpp.org>; Gabriel Dos Reis <g...@microsoft.com>; mod...@isocpp.org

Subject: Re: [isocpp-core] Example of the template visibility problem

_______________________________________________
Core mailing list
Co...@lists.isocpp.org
Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/core
Link to this post: http://lists.isocpp.org/core/2016/11/1260.php