Logical location of template instantiations

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Fri Jul 1 06:46:32 PDT 2016


On 07/01/2016 09:08 AM, Steven Schveighoffer wrote:
> On 6/27/16 12:25 PM, 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.
>
> I wonder what the plans are for std.allocator on this, as I would think
> it would run into the same issues. Andrei?

emplace only works with accessible constructors. I understand sometimes 
it's reasonable to ask for more flexibility, but there are limitations. 
-- Andrei



More information about the Digitalmars-d mailing list