Is there anything like the initializer list (C++) in D?

class Test {
	int x;
	Test(int y):x(y){};
}

Hoenir wrote:
> Is there anything like the initializer list (C++) in D?
> 
> class Test {
>     int x;
>     Test(int y):x(y){};
> }

class Test {
    int x ;
    this (int y) { x = y; }
}

;)  Or in short: no.  Not that I've ever missed it at all.

-- Chris Nicholson-Sauls

"Hoenir" <mrmocool@gmx.de> wrote in message news:f84rnt$1db0$1@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_lists_55262.html for an explanation on why D doesn't have them.

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=55262

Best regards,
Daniel

Thank you all for your answers :)

Jarrett Billingsley wrote:
> "Hoenir" <mrmocool@gmx.de> wrote in message news:f84rnt$1db0$1@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_lists_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.

-- James

Reply to James,

> Jarrett Billingsley wrote:
> 
>> "Hoenir" <mrmocool@gmx.de> wrote in message
>> news:f84rnt$1db0$1@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_;}
}

BCS wrote:
> Reply to James,
> 
>> Jarrett Billingsley wrote:
>>
>>> "Hoenir" <mrmocool@gmx.de> wrote in message news:f84rnt$1db0$1@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

James Dennett wrote:
> BCS wrote:
>> Reply to James,
>>
>>> Jarrett Billingsley wrote:
>>>
>>>> "Hoenir" <mrmocool@gmx.de> wrote in message
>>>> news:f84rnt$1db0$1@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