Re: Logical location of template instantiations

2016-07-08 Thread Jonathan M Davis via Digitalmars-d
On Friday, July 08, 2016 15:08:35 Timon Gehr via Digitalmars-d wrote: > On 08.07.2016 09:45, Jonathan M Davis via Digitalmars-d wrote: > > On Thursday, July 07, 2016 23:20:28 Timon Gehr via Digitalmars-d wrote: > >> On 07.07.2016 17:11, Jonathan M Davis via Digitalmars-d wrote: > >>>So, > >>>

Re: Logical location of template instantiations

2016-07-08 Thread Timon Gehr via Digitalmars-d
On 08.07.2016 09:45, Jonathan M Davis via Digitalmars-d wrote: On Thursday, July 07, 2016 23:20:28 Timon Gehr via Digitalmars-d wrote: On 07.07.2016 17:11, Jonathan M Davis via Digitalmars-d wrote: So, the buck would have to be passed at every point that the symbol were passed as an alias

Re: Logical location of template instantiations

2016-07-08 Thread Jonathan M Davis via Digitalmars-d
On Thursday, July 07, 2016 23:20:28 Timon Gehr via Digitalmars-d wrote: > On 07.07.2016 17:11, Jonathan M Davis via Digitalmars-d wrote: > > So, > > > > the buck would have to be passed at every point that the symbol were > > passed > > as an alias argument such that the check for accessibility

Re: Logical location of template instantiations

2016-07-07 Thread Timon Gehr via Digitalmars-d
On 07.07.2016 17:11, Jonathan M Davis via Digitalmars-d wrote: So, the buck would have to be passed at every point that the symbol were passed as an alias argument such that the check for accessibility was only done when the symbol first became an alias. ... No, it is way simpler than that.

Re: Logical location of template instantiations

2016-07-07 Thread Jonathan M Davis via Digitalmars-d
On Thursday, July 07, 2016 08:39:51 Steven Schveighoffer via Digitalmars-d wrote: > Yes, it is a problem. I still don't understand how the *calling* of a > private function is the problem, vs. the aliasing of it. Why aren't we > preventing the aliasing of the private function in the first place

Re: Logical location of template instantiations

2016-07-07 Thread Tofu Ninja via Digitalmars-d
On Thursday, 7 July 2016 at 12:39:51 UTC, Steven Schveighoffer wrote: Yes, it is a problem. I still don't understand how the *calling* of a private function is the problem, vs. the aliasing of it. Why aren't we preventing the aliasing of the private function in the first place (if not

Re: Logical location of template instantiations

2016-07-07 Thread Steven Schveighoffer via Digitalmars-d
On 7/7/16 7:49 AM, Tofu Ninja wrote: On Friday, 1 July 2016 at 19:13:45 UTC, Steven Schveighoffer wrote: Emplace needs a constructor alias parameter. -Steve That wouldn't work as emplace wouldn't be able to use the alias if it was private... void main(){ import other; test!foo();

Re: Logical location of template instantiations

2016-07-07 Thread Tofu Ninja via Digitalmars-d
On Friday, 1 July 2016 at 19:13:45 UTC, Steven Schveighoffer wrote: Emplace needs a constructor alias parameter. -Steve That wouldn't work as emplace wouldn't be able to use the alias if it was private... void main(){ import other; test!foo(); } private void foo(){} ##

Re: Logical location of template instantiations

2016-07-01 Thread Lodovico Giaretta via Digitalmars-d
On Friday, 1 July 2016 at 19:13:45 UTC, Steven Schveighoffer wrote: On 7/1/16 3:02 PM, Timon Gehr wrote: 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

Re: Logical location of template instantiations

2016-07-01 Thread Steven Schveighoffer via Digitalmars-d
On 7/1/16 3:02 PM, Timon Gehr wrote: 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,

Re: Logical location of template instantiations

2016-07-01 Thread 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

Re: Logical location of template instantiations

2016-07-01 Thread Jacob Carlborg via Digitalmars-d
On 01/07/16 16:14, Steven Schveighoffer wrote: Right, but this puts allocators at a lower footing than the GC which has no problem with private ctors. I would have expected to be able to build using allocators and private ctors. It's possible to bypass protection using pointers. -- /Jacob

Re: Logical location of template instantiations

2016-07-01 Thread Basile B. via Digitalmars-d
On Monday, 27 June 2016 at 16:25:27 UTC, Lodovico Giaretta wrote: [...] 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? Yes it would be worth. Several ppl have already hit

Re: Logical location of template instantiations

2016-07-01 Thread Basile B. via Digitalmars-d
On Friday, 1 July 2016 at 14:14:00 UTC, Steven Schveighoffer wrote: On 7/1/16 9:46 AM, Andrei Alexandrescu wrote: On 07/01/2016 09:08 AM, Steven Schveighoffer wrote: I wonder what the plans are for std.allocator on this, as I would think it would run into the same issues. Andrei?

Re: Logical location of template instantiations

2016-07-01 Thread Steven Schveighoffer via Digitalmars-d
On 7/1/16 9:46 AM, Andrei Alexandrescu wrote: On 07/01/2016 09:08 AM, Steven Schveighoffer wrote: 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

Re: Logical location of template instantiations

2016-07-01 Thread Jacob Carlborg via Digitalmars-d
On 01/07/16 15:46, Andrei Alexandrescu wrote: emplace only works with accessible constructors. I understand sometimes it's reasonable to ask for more flexibility, but there are limitations. It's possible to bypass the protection using a pointer. An alternative would be to not invoke the

Re: Logical location of template instantiations

2016-07-01 Thread Andrei Alexandrescu via Digitalmars-d
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);

Re: Logical location of template instantiations

2016-07-01 Thread Jacob Carlborg via Digitalmars-d
On 01/07/16 11:57, Lodovico Giaretta wrote: Ping... Maybe I'm just saying bullshit, but... Am I really the only one who faced this need? You're not the only one, it's been brought up before. A solution/workaround is that "emplace" invokes the constructor using a function pointer, what will

Re: Logical location of template instantiations

2016-07-01 Thread Steven Schveighoffer via Digitalmars-d
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

Re: Logical location of template instantiations

2016-07-01 Thread Enamex via Digitalmars-d
On Friday, 1 July 2016 at 12:08:49 UTC, Lodovico Giaretta wrote: On Friday, 1 July 2016 at 11:45:12 UTC, Robert burner Schadek wrote: IMO, this is one of these places where theory meets practice. Do what works, write a comment explaining the problem, and move on ;-) Yes, well, I successfully

Re: Logical location of template instantiations

2016-07-01 Thread Lodovico Giaretta via Digitalmars-d
On Friday, 1 July 2016 at 11:45:12 UTC, Robert burner Schadek wrote: IMO, this is one of these places where theory meets practice. Do what works, write a comment explaining the problem, and move on ;-) Yes, well, I successfully bypassed my issues with this thing, but I wanted to share my

Re: Logical location of template instantiations

2016-07-01 Thread Robert burner Schadek via Digitalmars-d
IMO, this is one of these places where theory meets practice. Do what works, write a comment explaining the problem, and move on ;-)

Re: Logical location of template instantiations

2016-07-01 Thread Lodovico Giaretta via Digitalmars-d
Ping... Maybe I'm just saying bullshit, but... Am I really the only one who faced this need?

Logical location of template instantiations

2016-06-27 Thread Lodovico Giaretta via Digitalmars-d
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