digitalmars.D - auto with array of strings (BUG?)
- Justin <mrjnewt gmail.com> Aug 19 2009
- Jarrett Billingsley <jarrett.billingsley gmail.com> Aug 19 2009
- Justin <mrjnewt gmail.com> Aug 19 2009
- BCS <ao pathlink.com> Aug 19 2009
- Jarrett Billingsley <jarrett.billingsley gmail.com> Aug 19 2009
- bearophile <bearophileHUGS lycos.com> Aug 20 2009
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
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=
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]=
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=
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
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
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.
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
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
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









Justin <mrjnewt gmail.com> 