www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - auto with array of strings (BUG?)

reply Justin <mrjnewt gmail.com> writes:
I was writing some unittests when I ran across some rather unexpected behavior
in which strings in an array were being trimmed to the length of the first
element. Running this program:

import std.stdio;
void main() {
	auto strings = ["hello", "cruelly", "innovative", "world"];
	writefln(strings);
}

produces this:
[[h,e,l,l,o],[c,r,u,e,l],[i,n,n,o,v],[w,o,r,l,d]]

as the compiler decides to make the strings variable an array of char[5u]. The
problem is easily avoided by replacing auto with string[], but the problem
caught me off guard while working in the one place where I regularly use auto:
unittests.

Is there a reason that the compiler makes the assumptions it does or is this a
bug? I did try searching the bugzilla with a few different queries, but failed
to turn up anything that looked likely.
Aug 19 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, Aug 19, 2009 at 7:01 PM, Justin<mrjnewt gmail.com> wrote:

 I was writing some unittests when I ran across some rather unexpected beh=


avior in which strings in an array were being trimmed to the length of the =
first element. Running this program:

 import std.stdio;
 void main() {
 =A0 =A0 =A0 =A0auto strings =3D ["hello", "cruelly", "innovative", "world=


"];

 =A0 =A0 =A0 =A0writefln(strings);
 }

 produces this:
 [[h,e,l,l,o],[c,r,u,e,l],[i,n,n,o,v],[w,o,r,l,d]]

 as the compiler decides to make the strings variable an array of char[5u]=


. The problem is easily avoided by replacing auto with string[], but the pr=
oblem caught me off guard while working in the one place where I regularly =
use auto: unittests.

 Is there a reason that the compiler makes the assumptions it does or is t=


his a bug? I did try searching the bugzilla with a few different queries, b=
ut failed to turn up anything that looked likely.

There's two annoying things going on here:

1) The type of string literals is not char[], it's char[n] where n is
the length of the string.  I don't know why this is.
2) With array literals, the compiler simply determines the type of the
array as being a dynamic array of the type of the first element,
rather than making it an array of the common type of all the elements.

That being said I have no idea why the compiler is allowing "cruelly",
which is of type char[7], to be implicitly converted to char[5].  I
thought that was not legit.
Aug 19 2009
next sibling parent reply Justin <mrjnewt gmail.com> writes:
Jarrett Billingsley Wrote:

 There's two annoying things going on here:
 
 1) The type of string literals is not char[], it's char[n] where n is
 the length of the string.  I don't know why this is.
 2) With array literals, the compiler simply determines the type of the
 array as being a dynamic array of the type of the first element,
 rather than making it an array of the common type of all the elements.
 
 That being said I have no idea why the compiler is allowing "cruelly",
 which is of type char[7], to be implicitly converted to char[5].  I
 thought that was not legit.


Adding const to the auto declaration will cause an error at compile time.
Aug 19 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, Aug 19, 2009 at 7:20 PM, Justin<mrjnewt gmail.com> wrote:

 Jarrett Billingsley Wrote:

 There's two annoying things going on here:

 1) The type of string literals is not char[], it's char[n] where n is
 the length of the string. =A0I don't know why this is.
 2) With array literals, the compiler simply determines the type of the
 array as being a dynamic array of the type of the first element,
 rather than making it an array of the common type of all the elements.

 That being said I have no idea why the compiler is allowing "cruelly",
 which is of type char[7], to be implicitly converted to char[5]. =A0I
 thought that was not legit.


 Adding const to the auto declaration will cause an error at compile time.


Weird.
Aug 19 2009
prev sibling parent BCS <ao pathlink.com> writes:
Reply to Jarrett,


 On Wed, Aug 19, 2009 at 7:01 PM, Justin<mrjnewt gmail.com> wrote:
 

 I was writing some unittests when I ran across some rather unexpected
 behavior in which strings in an array were being trimmed to the
 length of the first element. Running this program:
 
 import std.stdio;
 void main() {
 auto strings = ["hello", "cruelly", "innovative", "world"];
 writefln(strings);
 }
 produces this:
 [[h,e,l,l,o],[c,r,u,e,l],[i,n,n,o,v],[w,o,r,l,d]]
 as the compiler decides to make the strings variable an array of
 char[5u]. The problem is easily avoided by replacing auto with
 string[], but the problem caught me off guard while working in the
 one place where I regularly use auto: unittests.
 
 Is there a reason that the compiler makes the assumptions it does or
 is this a bug? I did try searching the bugzilla with a few different
 queries, but failed to turn up anything that looked likely.
 


 There's two annoying things going on here:
 
 1) The type of string literals is not char[], it's char[n] where n is
 the length of the string.  I don't know why this is.
 2) With array literals, the compiler simply determines the type of the
 array as being a dynamic array of the type of the first element,
 rather than making it an array of the common type of all the elements.
 That being said I have no idea why the compiler is allowing "cruelly",
 which is of type char[7], to be implicitly converted to char[5].  I
 thought that was not legit.
 


the solution is to use

auto strings = ["hello"[], "cruelly", "innovative", "world"];
Aug 19 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Justin:


Is there a reason that the compiler makes the assumptions it does or is this a
bug? I did try searching the bugzilla with a few different queries, but failed
to turn up anything that looked likely.<


I don't know if it can be considered a bug, or just a design error. What I know
is that it's a bug-prone feature of D1. It will be partially fixed in D2, but
I'd like to see such feature changed in D1 too, that is I'd like array/string
literals to produce dynamic arrays by default (and then to have another syntax
to specify fixed-size arrays).
Dynamic arrays are more flexible and safer, so according to the D philosophy
they have to be the default case :-)

Bye,
bearophile
Aug 20 2009