www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Bug? tupleof and const string = ""

reply Andre <andre s-e-a-p.de> writes:
Hi,

could you have a look whether this is a bug with tupleof?
In case you have a const string with a default value,
the attribute is not in the tupleof list.

struct A {
	const string a = "abc";
	string d;
}

void main(){
	assert(A().tupleof.length == 2); // fails -> length = 1
}

Kind regards
André
Feb 13 2014
next sibling parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
On Thursday, 13 February 2014 at 16:37:20 UTC, Andre wrote:

 Hi,

 could you have a look whether this is a bug with tupleof?
 In case you have a const string with a default value,
 the attribute is not in the tupleof list.

 struct A {
 	const string a = "abc";
 	string d;
 }

 void main(){
 	assert(A().tupleof.length == 2); // fails -> length = 1
 }

 Kind regards
 André


I'm not sure. May guess is the compiler figures that you'll never 
be able to change a and pulls it out of the struct. What I don't 
know is, if it should do this without using immutable or enum.

Besides: I don't think that const elements make any sense. What 
do you want to do?
Feb 13 2014
parent Andre <andre s-e-a-p.de> writes:
Am 13.02.2014 17:42, schrieb Tobias Pankrath:

 On Thursday, 13 February 2014 at 16:37:20 UTC, Andre wrote:

 Hi,

 could you have a look whether this is a bug with tupleof?
 In case you have a const string with a default value,
 the attribute is not in the tupleof list.

 struct A {
     const string a = "abc";
     string d;
 }

 void main(){
     assert(A().tupleof.length == 2); // fails -> length = 1
 }

 Kind regards
 André


 I'm not sure. May guess is the compiler figures that you'll never be
 able to change a and pulls it out of the struct. What I don't know is,
 if it should do this without using immutable or enum.

 Besides: I don't think that const elements make any sense. What do you
 want to do?


It is strange, const string attributes without a value are working fine.

The use case is for communication with a database procedure. The 
database procedure want the request in JSON format. I created the
structure similiar to the JSON request and serialize it to JSON.
Some of the values should be constant others should be variable.

Kind regards
André
Feb 13 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andre:


 could you have a look whether this is a bug with tupleof?
 In case you have a const string with a default value,
 the attribute is not in the tupleof list.

 struct A {
 	const string a = "abc";
 	string d;
 }

 void main(){
 	assert(A().tupleof.length == 2); // fails -> length = 1
 }


Tupleeof is working correctly here. Currently const/immutable 
fields don't become struct instance fields. After a transition 
phase this will be changed, and in some months you will see two 
fields there. DMD 2.065 has a warning on this.

Bye,
bearophile
Feb 13 2014
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 13 February 2014 at 16:52:58 UTC, bearophile wrote:

 Andre:


 could you have a look whether this is a bug with tupleof?
 In case you have a const string with a default value,
 the attribute is not in the tupleof list.

 struct A {
 	const string a = "abc";
 	string d;
 }

 void main(){
 	assert(A().tupleof.length == 2); // fails -> length = 1
 }


 Tupleeof is working correctly here. Currently const/immutable 
 fields don't become struct instance fields. After a transition 
 phase this will be changed, and in some months you will see two 
 fields there. DMD 2.065 has a warning on this.

 Bye,
 bearophile


Don't you mean const/immutable fields with initialisers don't 
become instance fields? Or is this actually as strange as it 
sounds?
Feb 13 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 13 February 2014 at 16:57:19 UTC, John Colvin wrote:

 Don't you mean const/immutable fields with initialisers don't 
 become instance fields? Or is this actually as strange as it 
 sounds?


Yes, it is legacy behavior (== bug) that persisted since D1 days 
and was addressed only recently. Until this 
deprecation/transition process will end this:

struct X
{
     const string value = "literal"'
}

is effectively same as this:

struct X
{
     enum value = "literal"'
}
Feb 13 2014
parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 13 February 2014 at 17:12:28 UTC, Dicebot wrote:

 On Thursday, 13 February 2014 at 16:57:19 UTC, John Colvin 
 wrote:

 Don't you mean const/immutable fields with initialisers don't 
 become instance fields? Or is this actually as strange as it 
 sounds?


 Yes, it is legacy behavior (== bug) that persisted since D1 
 days and was addressed only recently. Until this 
 deprecation/transition process will end this:

 struct X
 {
     const string value = "literal";
 }

 is effectively same as this:

 struct X
 {
     enum value = "literal";
 }


To be anal, it's technically the same as:

struct X
{
      static const string value = "literal";
}

The immutable/const member will be made a static member, which
you can deference, or pass by reference.
Feb 13 2014
prev sibling parent Andre <andre s-e-a-p.de> writes:
Am 13.02.2014 17:52, schrieb bearophile:

 Andre:


 could you have a look whether this is a bug with tupleof?
 In case you have a const string with a default value,
 the attribute is not in the tupleof list.

 struct A {
     const string a = "abc";
     string d;
 }

 void main(){
     assert(A().tupleof.length == 2); // fails -> length = 1
 }


 Tupleeof is working correctly here. Currently const/immutable fields
 don't become struct instance fields. After a transition phase this will
 be changed, and in some months you will see two fields there. DMD 2.065
 has a warning on this.

 Bye,
 bearophile



Thanks for the info. Time to update to 2.065:)

Kind regards
André
Feb 13 2014