www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Private struct constructor

reply Ritchie <ritchie shark.at> writes:
Any reason why this works?

https://run.dlang.io/is/TALlyw
Oct 04 2018
next sibling parent reply Andrea Fontana <nospam example.com> writes:
On Thursday, 4 October 2018 at 07:31:21 UTC, Ritchie wrote:
 Any reason why this works?

 https://run.dlang.io/is/TALlyw
Why not?
Oct 04 2018
parent Ritchie <ritchie shark.at> writes:
On Thursday, 4 October 2018 at 07:55:48 UTC, Andrea Fontana wrote:
 On Thursday, 4 October 2018 at 07:31:21 UTC, Ritchie wrote:
 Any reason why this works?

 https://run.dlang.io/is/TALlyw
Why not?
The constructor is private.
Oct 04 2018
prev sibling next sibling parent John Chapman <johnch_atms hotmail.com> writes:
On Thursday, 4 October 2018 at 07:31:21 UTC, Ritchie wrote:
 Any reason why this works?

 https://run.dlang.io/is/TALlyw
"private" applies to the module, not the type. https://dlang.org/spec/attribute.html#visibility_attributes
Oct 04 2018
prev sibling parent reply Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Thursday, 4 October 2018 at 07:31:21 UTC, Ritchie wrote:
 Any reason why this works?

 https://run.dlang.io/is/TALlyw
Yup. Alright, so there's a few features in use here - which one are you asking about? 1. Private constructor. You can call the private constructor because the unit of encapsulation in D is the module, not the type. So everything is visible to everything else inside the same module. 2. disable this() This only disables default construction. Since you call a different constructor, this doesn't affect the compilation. 3. disable this(this) This disables copy construction. In the example, no copying occurs - the variable declaration leads to a move instead. Simply put, copy construction requires that two copies exist simultaneously, and in this case the potential second copy is immediately destroyed, so no copy is necessary. 4. disable void opAssign() There's several reasons this doesn't affect compilation here. First, the signature is wrong - you're disabling an opAssign that takes no arguments. You're probably wanting to do disable void opAssign(X x);. Now, even that isn't going to cause it to fail to compile in this construction, not assignment. To force an assignment, you need to have an object already: X x = void; x = X(5); // calls opAssign So, now we've explained why it compiles. Currently, there's no way to disable or hook move construction. There's a DIP in the works (DIP 1014) that aims to provide a hook into move construction, but I don't see that it allows for disabling it altogether. Hope this helps! -- Simen
Oct 04 2018
parent reply Ritchie <ritchie shark.at> writes:
On Thursday, 4 October 2018 at 08:14:44 UTC, Simen Kjærås wrote:
 On Thursday, 4 October 2018 at 07:31:21 UTC, Ritchie wrote:
 Any reason why this works?

 https://run.dlang.io/is/TALlyw
Yup. Alright, so there's a few features in use here - which one are you asking about? 1. Private constructor. You can call the private constructor because the unit of encapsulation in D is the module, not the type. So everything is visible to everything else inside the same module. 2. disable this() This only disables default construction. Since you call a different constructor, this doesn't affect the compilation. 3. disable this(this) This disables copy construction. In the example, no copying occurs - the variable declaration leads to a move instead. Simply put, copy construction requires that two copies exist simultaneously, and in this case the potential second copy is immediately destroyed, so no copy is necessary. 4. disable void opAssign() There's several reasons this doesn't affect compilation here. First, the signature is wrong - you're disabling an opAssign that takes no arguments. You're probably wanting to do disable void opAssign(X x);. Now, even that isn't going to cause it to fail to compile in is move construction, not assignment. To force an assignment, you need to have an object already: X x = void; x = X(5); // calls opAssign So, now we've explained why it compiles. Currently, there's no way to disable or hook move construction. There's a DIP in the works (DIP 1014) that aims to provide a hook into move construction, but I don't see that it allows for disabling it altogether. Hope this helps! -- Simen
I apologize for not making it clear. I was talking about the private constructor only. The disable this() is there to prevent struct literal syntax and the other disables really have no reason to be there for the purpose of this question. Oddly enough I asked this because I was working on something and was able to call the private constructor from another module, but then I created the run.dlang.io snippet to demo my problem. I have this in one module: https://pastebin.com/J8r4fyK8 and this in another module: void testUniquePtr() { import bclib.memory.unique_ptr : Unique; alias TestUnique = Unique!(int, TestMallocator); { auto unique = TestUnique(20); assert(*unique == 20); } TestMallocator.check(); } and it runs without complaints. (SmartPtrMembers doesnt have any constructors in it)
Oct 04 2018
parent reply Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Thursday, 4 October 2018 at 08:52:50 UTC, Ritchie wrote:
 I apologize for not making it clear. I was talking about the 
 private constructor only. The  disable this() is there to 
 prevent struct literal syntax and the other disables really 
 have no reason to be there for the purpose of this question.

 Oddly enough I asked this because I was working on something 
 and was able to call the private constructor from another 
 module, but then I created the run.dlang.io snippet to demo my 
 problem.
Right. Reduced your example to this: module bar; struct S() { private this()(int n) {} } module foo; unittest { import bar; auto a = S!()(3); } This is apparently a known issue: https://issues.dlang.org/show_bug.cgi?id=18979 which is basically just a special case of this issue: https://issues.dlang.org/show_bug.cgi?id=2775 -- Simen
Oct 04 2018
parent Ritchie <ritchie shark.at> writes:
On Thursday, 4 October 2018 at 09:21:39 UTC, Simen Kjærås wrote:
 This is apparently a known issue:

 https://issues.dlang.org/show_bug.cgi?id=18979

 which is basically just a special case of this issue:

 https://issues.dlang.org/show_bug.cgi?id=2775

 --
   Simen
I see. Looks like the chances of it being fixed anytime soon are slim. Thanks for the info.
Oct 04 2018