Static inline field initialization

Moritz Maxeiner via Digitalmars-d digitalmars-d at puremagic.com
Tue Aug 22 08:01:22 PDT 2017


On Tuesday, 22 August 2017 at 12:38:50 UTC, Jonas Mminnberg wrote:
> On Tuesday, 22 August 2017 at 12:20:45 UTC, Moritz Maxeiner 
> wrote:
>
>>
>> I agree that it can be confusing if you try to read it with 
>> C++ semantics [1]; the solution, however, imho is not to 
>> change D semantics or throw warnings [2], but to refer to the 
>> D spec [3], which states that static initialization of class 
>> members is used instead of default initialization (before any 
>> constructors are run). To me that means a statically 
>> initialized class field shall have the same value in all class 
>> instances, i.e. it's not silent sharing, you explicitly 
>> requested the sharing. If that doesn't mean the same to 
>> others, the D spec wording should be updated to be clearer on 
>> the subject.
>> If you don't want instances to share a field value, instead of 
>> static initialization you can use constructor initialization 
>> [4]:
>>
>> ----
>> class Test
>> {
>>     ubyte[] buf;
>>     this()
>>     {
>>         buf = new ubyte[1000];
>>     }
>>  }
>>
>> void main()
>> {
>>     auto a = new Test();
>>     auto b = new Test();
>>     assert(a.buf.ptr != b.buf.ptr);
>> }
>
> I know that it is according to the standard but since D has 
> gone out of it's way to make sure sharing doesn't occur 
> otherwise, by defaulting to TLS storage etc,

While I can understand the sentiment, there is a difference 
between sharing data between threads and sharing data between 
class instances in the same thread, the latter of which is 
occurring here.
There is a bug with static field initializers (as others have 
pointed out), but it's about the fact that the array is stored in 
global storage and not in TLS and doesn't apply in the example 
above.

> I feel this breaks the "no surprises" rule.
> I took me a long time to find this out and when I mentioned it 
> to other casual D programmers they also had no idea this was 
> how it worked.

While I don't find how it works surprising personally (it's 
consistent with how static initialization works everywhere else 
in D) - in contrast to other subtleties in D - it might make be 
sensible to include this in the Dlang tour.


More information about the Digitalmars-d mailing list