p.s. also note that module can has several static ctors, i.e. this works fine:

=== z00.d ===

module z00;

import std.stdio;

static this () { writeln("ctor0"); }

static this () { writeln("ctor1"); }


=== z01.d ===

module z01;

import z00;

void main () {}


this prints:
ctor0
ctor1


so you can several initialization functions to module with, for example, mixins.

On Monday, 29 June 2015 at 02:31:18 UTC, ketmar wrote:
> yes. it doesn't do that now, afair, but i can't see any sense in running code that obviously does nothing, as it's owner is not used. module ctors was designed for such things -- i.e. to run some code on startup. if someone is doing some vital initialization in static ctor of struct or class, and that struct or class aren't used anywhere else in his code, he's doing it wrong. it *may* work now, but that's simply 'cause compiler is not very well at removing unused code.

That seems wrong, what if I am doing separate compilation, how would the compiler know if the type is going to be used or not...

On Mon, 29 Jun 2015 03:10:44 +0000, Tofu Ninja wrote:

> On Monday, 29 June 2015 at 02:31:18 UTC, ketmar wrote:
>> yes. it doesn't do that now, afair, but i can't see any sense in running code that obviously does nothing, as it's owner is not used. module ctors was designed for such things -- i.e. to run some code on startup. if someone is doing some vital initialization in static ctor of struct or class, and that struct or class aren't used anywhere else in his code, he's doing it wrong. it *may* work now, but that's simply 'cause compiler is not very well at removing unused code.
> 
> That seems wrong, what if I am doing separate compilation, how would the compiler know if the type is going to be used or not...

it doesn't really matter if you compiled your code separate or not: compiler *has* to know everything to successfully link the program. and it knows. for now it doesn't do much with that info, though, as using binutils for languages like D sux: D needs it's own compiled module format and optimising linker.

but as i told ealier, this is the limitiation of current implementation, not guarantee.

On Monday, 29 June 2015 at 02:07:57 UTC, ketmar wrote:
> On Sat, 27 Jun 2015 22:49:13 +0000, Tofu Ninja wrote:
>
>> On Saturday, 27 June 2015 at 22:20:40 UTC, ketmar wrote:
>>> 2. no.
>> 
>> Hmm...  any reason why?
>
> if instantiated template was not used in any code that makes into compiled binary, compiler is free to remove it with all it's ctors. it may do that, or may not, but removal is allowed. so while that can work now (i didn't checked), it may stop working in next version (or with another compiler), and that will not be a bug.

Does the specification really say that? This isn't obvious to me at all. I would expect static ctors to be treated as if they were "referenced" by the initialization logic (though I understand it's not an explicit reference, they just end up in a special section that the runtime can inspect).

On Mon, 29 Jun 2015 10:19:33 +0000, Marc Schütz wrote:

> On Monday, 29 June 2015 at 02:07:57 UTC, ketmar wrote:
>> On Sat, 27 Jun 2015 22:49:13 +0000, Tofu Ninja wrote:
>>
>>> On Saturday, 27 June 2015 at 22:20:40 UTC, ketmar wrote:
>>>> 2. no.
>>> 
>>> Hmm...  any reason why?
>>
>> if instantiated template was not used in any code that makes into
>> compiled binary, compiler is free to remove it with all it's ctors. it
>> may do that, or may not, but removal is allowed.
>> so while that can work now (i didn't checked), it may stop working in
>> next version (or with another compiler), and that will not be a bug.
> 
> Does the specification really say that? This isn't obvious to me at all. I would expect static ctors to be treated as if they were "referenced" by the initialization logic (though I understand it's not an explicit reference, they just end up in a special section that the runtime can inspect).

it doesn't, afair, but it's quite natural. if user type was throwed out as unused, it would be very strange to insist on keeping it's initialization code.

On Monday, 29 June 2015 at 11:36:42 UTC, ketmar wrote:
> it doesn't, afair, but it's quite natural. if user type was throwed out as unused, it would be very strange to insist on keeping it's initialization code.

Yes, but I would instead expect that the static ctor prevents the type from becoming unused in the first place.

On Monday, 29 June 2015 at 11:36:42 UTC, ketmar wrote:
> it doesn't, afair, but it's quite natural. if user type was throwed out as unused, it would be very strange to insist on keeping it's initialization code.

Personally I would be kinda pissed if the compiler did this, I expect the static ctor to run, even if I don't use the type.

On 6/26/15 6:00 PM, Tofu Ninja wrote:
> Also are static constructors in templated types guaranteed to run for
> every instantiation?

I'd hazard to guess that the current compiler does run them, but that they probably aren't guaranteed to run by a sufficiently smart future compiler.

Note, I strongly would discourage having static ctors inside templates:

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

-Steve

On Mon, 29 Jun 2015 17:22:17 +0000, Marc Schütz wrote:

> On Monday, 29 June 2015 at 11:36:42 UTC, ketmar wrote:
>> it doesn't, afair, but it's quite natural. if user type was throwed out as unused, it would be very strange to insist on keeping it's initialization code.
> 
> Yes, but I would instead expect that the static ctor prevents the type from becoming unused in the first place.

and i expect it to be thrown away. ;-) as we have module-scope static ctors to initialize various things that should be always initialized. and type static ctor -- by my logic deduction -- should only initialize internal type fields. and why should i even bother to initialize that internal fields if the type is not used anywhere?

On Wednesday, 1 July 2015 at 07:55:20 UTC, ketmar wrote:
> On Mon, 29 Jun 2015 17:22:17 +0000, Marc Schütz wrote:
>
>> On Monday, 29 June 2015 at 11:36:42 UTC, ketmar wrote:
>>> it doesn't, afair, but it's quite natural. if user type was throwed out as unused, it would be very strange to insist on keeping it's initialization code.
>> 
>> Yes, but I would instead expect that the static ctor prevents the type from becoming unused in the first place.
>
> and i expect it to be thrown away. ;-) as we have module-scope static ctors to initialize various things that should be always initialized. and type static ctor -- by my logic deduction -- should only initialize internal type fields. and why should i even bother to initialize that internal fields if the type is not used anywhere?

The behaviour you expect makes more sense, for sure, but I was trying to guess what the current implementation might be doing without actually having to try it :-)