Logical location of template instantiations

[Timon Gehr via Digitalmars-d]

On 27.06.2016 18:25, Lodovico Giaretta wrote:
> import std.conv, core.memory;
>
> struct S
> {
>      int x;
>      private this(int val)
>      {
>          x = val;
>      }
> }
>
> void main()
> {
>      auto ptr = cast(S*)GC.malloc(S.sizeof);
>      auto s = ptr.emplace(3);
> }
>
> This code does not work, as  the call `ptr.emplace(3)` creates a new
> concrete implementation of emplace with parameters `S` and `int`, which
> logically belongs to module std.conv, and so has no access to the
> private constructor.
>
> But, logically speaking, as I'm able to construct objects of S, I should
> also be able to emplace them (which is the same thing, logically) while
> inside my module. What I mean is that in this situation it would be
> better if the call `ptr.emplace(3)` created a new concrete
> implementation of emplace inside the module that called it, to have the
> correct access permissions.
>
> This is not the first time I run into this limitation (not only with
> functions, but also with structs), so I wonder: wouldn't it be worth a
> way to get this behaviour?
>
> Thank you for your time.
>
> Lodovico Giaretta

The current module (that declares 'S') might not be the only module that 
uses emplace to construct 'S' instances. We want to hide the constructor 
of 'S' from other modules, but not from the current module.
But both modules get identical template instances, so either both see 
the private constructor (through emplace), or none does. To fix this 
properly, there should hence be a way for the two modules to receive 
distinct template instances.