Problem with coupling shared object symbol visibility with protection

[Benjamin Thaut via Digitalmars-d]

On Thursday, 29 January 2015 at 10:21:25 UTC, Walter Bright wrote:
> On 1/28/2015 5:19 AM, Benjamin Thaut wrote:
>> On Wednesday, 28 January 2015 at 11:01:09 UTC, Walter Bright 
>> wrote:
>>
>>> The example had marked the template itself as 'export'. This 
>>> raises the
>>> specter of which binary the template instantiation exists in.
>>>
>>
>> The export in this context actually means "export all 
>> instanciations of this
>> template". And this is needed to avoid using -allinst 
>> everywhere.
>
> The problem is what happens when the client side instantiates 
> the template, which it must in order to use it.

Well if there already is a statically known instanciation it will 
not instanciate it. (I didn't change that behvaior). The question 
is what happens when you have something like this:

module a:
struct SomeTemplate(T){}
alias knownInstance = SomeTemplate!int;

module b:
SomeTemplate!int var1; // will use instanciation from a (unless 
-allinst)
SomeTemplate!float var2; // will instanciate
alias knownInstance2 = SomeTemplate!uint;

module c:
SomeTemplate!uint var3; // will this use instaction from b? Or 
instanciate itself?

I don't know enough about D's template implementation to answer 
the question regarding c.var3. Depending on the answer to this 
question I can answer what should happen if a export marked 
template is instanciated outside of its module. (e.g. by the user)

Please also correct me if any of the above assumptions are 
incorrect.