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