initializer list like in C++?

[Chris Nicholson-Sauls]

James Dennett wrote:
> BCS wrote:
>> Reply to James,
>>
>>> Jarrett Billingsley wrote:
>>>
>>>> "Hoenir" <mrmocool at gmx.de> wrote in message
>>>> news:f84rnt$1db0$1 at digitalmars.com...
>>>>
>>>>> Is there anything like the initializer list (C++) in D?
>>>>>
>>>>> class Test {
>>>>> int x;
>>>>> Test(int y):x(y){};
>>>>> }
>>>> No.  See
>>>> http://www.digitalmars.com/d/archives/digitalmars/D/initialization_li
>>>> sts_55262.html for an explanation on why D doesn't have them.
>>>>
>>> I looked at that thread, but found only references to performance,
>>> which miss the main reason why these are present/useful in C++:
>>> semantics.  There are various kinds of things in C++ that can be
>>> initialized but cannot be modified, because of references, const-ness,
>>> and classes with immutable value semantics.
>>>
>>> The occasional/slight performance benefit is definitely secondary to
>>> the ability to express meaning directly in the code.
>>>
>>> As D gains the ability to model such immutable members, it might
>>> benefit from finding (its own) solution to the same issue.
>>>
>> IIRC  this works
>>
>> const int i;
>> static this(){i=5;}
>>
>> class C
>> {
>>   const char c;
>>   this(char c_){c=c_;}
>> }
> 
> Can c be modified more than once during construction?  If not,
> what rules are used to determine when it's been modified?
> 
> Java came up with "definite assignment" rules for this kind of
> things, and they're pretty decent -- they guarantee that a final
> value is assigned a value exactly once, while allowing for some
> flexibility such as setting it down all branches of an if/else.
> 
> -- James

As I understand it:

=== D/1.x ===
Const fields/variables can be assigned and otherwise modified freely 
within relevant constructors, being otherwise iron-clad.  I believe its 
a compile-time check only, with available hardware protections at runtime.

=== D/2.x ===
Final fields/variables are assign-once, from anywhere, with some check 
bit being set thereafter to prevent rebinding.  Const takes on a meaning 
relevant to the actual data only, and so means nothing for the 
discussion at hand.  (I may be wrong; for example, it may be that 
constructors specifically take liberties with 2.x final as they do with 
1.x const.)

-- Chris Nicholson-Sauls