www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 481] New: Letting compiler determine length for fixed-length arrays

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=481

           Summary: Letting compiler determine length for fixed-length
                    arrays
           Product: D
           Version: 0.172
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: wbaxter gmail.com


There needs to be a way to tell the compiler to count up how many elements
there are in a fixed length array.  In C++ you use empty brackets, [], but in D
this means "create a dynamic array".  Sometimes you want a fixed-length array
but it's a pain to count up the elements by hand.  The main example is
embedding binary data, like images, into the program as code.

A possible syntax would be to use the pre-existing '$' or 'length' indicators
to specify that the length of the array should be the length of the
initializer:

   int arr[$] = [1,2,3,4];  // makes an int[4]
   int arr[length] = [1,2,3,4];  // ditto
   int[$] arr = [1,2,3,4];  //  ditto
   int[length] arr = [1,2,3,4];  // ditto

Another option would be to re-use the keyword auto.
   int arr[auto] = [1,2,3,4];  // makes an int[4]
   int[auto] arr = [1,2,3,4];  //  ditto

Using 'auto' makes sense in that the length really is part of the type of a
fixed-length array, so really what you're saying is "automatically deduce just
this part of the type for me".

Using 'auto' would also be extend naturally to associative arrays when/if there
are initializers for those.  For example:

   int[auto] str_to_num = [ "one":1, "two":2, "three":3 ];

This would specify that value type is int, but let the key type be
automatically deduced from the initializer.


--
Nov 04 2006
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=481


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |andrei metalanguage.com
         AssignedTo|nobody puremagic.com        |bugzilla digitalmars.com



11:36:34 PST ---
This enhancement's importance is raised by the fact that array literals have
dynamic length by default, so simply writing

auto a = [1,2,3,4];

won't make a of type int[4].

I think using "[$]" is the most sensible option. The special meaning of
"length" inside array brackets needs to be eliminated anyway, and "[auto]" may
confuse people into thinking it's an associative array.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 26 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=481


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc



I agree that this syntax is good:
int[$] arr = [1,2,3,4];

But it solves only half of the problem.
Currently this compiles:

int[4] a = [1, 2, 3];
void main() {}

While this generates:
object.Exception: lengths don't match for array copy

void main() {
    int[4] a = [1, 2, 3]; 
}

They are two different situations. But they don't look different, the first
just look like a special case.

To solve the second half of the problem someone has suggested this syntax that
looks good enough:
int[4] a = [1, 2, 3, ...];
a[3] is filled with typeof(a[0]).init.

For more info see bug 3849

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 26 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=481


Bruno Medeiros <bdom.pub+deebugz gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bdom.pub+deebugz gmail.com



05:28:18 PST ---


 This enhancement's importance is raised by the fact that array literals have
 dynamic length by default, so simply writing
 
 auto a = [1,2,3,4];
 
 won't make a of type int[4].
 
 I think using "[$]" is the most sensible option. 


I don't quite get this argument. If you have a syntax such as "[$]" (I assume
you are referring to Bill's example of "int[$] arr"), then obviously
  auto a = [1,2,3,4];
still won't make a of type int[4]... 

The only way to use auto (in it current form) to declare a static array would
be to have a syntax for a static array literal. Or to have a template and/or
function to create the static array value. Isn't this latter alternative
preferable? A bit more verbose, but no language changes should be necessary.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 03 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=481






 I don't quite get this argument.


Originally array literals used to create fixed length arrays:

auto a = [1,2,3,4];
==> int[4]

Later D was changed so that line creates a dynamic array:

auto a = [1,2,3,4];
==> int[]

that's handy, but now if you have a long array literal and you want a
fixed-sized array you have to count how many items it has. This is not handy,
especially if later you want to add or remove items from the array literal (in
the source code).

It's not handy also because if by mistake you write a bigger number, empty
items are silently created (but only for global fixed-sized literals):

int[5] a = [1,2,3,4];
==> int[5]

So Bill and others have suggested a simple syntax that is easy enough to read,
understand and remember:

int[$] a = [1,2,3,4];
==> int[4]

And to avoid bugs produced by wrong number of items a second syntax may be
introduced, that makes it explicit that there are some auto initialized items:

int[6] a = [1,2,3,4,...];
==> int[6]

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 11 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=481




04:27:54 PST ---




 I don't quite get this argument.


 
 Originally array literals used to create fixed length arrays:



Yes, I understood the use case for this problem, and how the [$] syntax would
solve the limitation in a way. 
But then we're not looking for a syntax that would also allows us to use auto
(as in "auto a = [1,2,3,4];"), is that what we're saying?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 14 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=481







 But then we're not looking for a syntax that would also allows us to use auto
 (as in "auto a = [1,2,3,4];"), is that what we're saying?


Now I think I understand what you mean. You mean something like:
auto[$] a = [1,2,3,4];
==> int[4]
So auto lets the D compiler infer the element type and count the items, but the
result is a fixed-length array still.

I think this case is not common enough to deserve a third syntax.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 14 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=481




02:15:21 PST ---
This is a very low priority issue.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=481






 This is a very low priority issue.


Well, I don't agree. It's a language design issue, so its priority is higher
than most implementation matters.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=481


thelastmammoth gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thelastmammoth gmail.com







 This is a very low priority issue.


 
 Well, I don't agree. It's a language design issue, so its priority is higher
 than most implementation matters.


See proposal [Issue 8008] for a simpler alternative: auto x=[1,2,3]S (or auto
x=[1,2,3]f). 
I believe it makes [$] mostly irrelevant, and has other advantages.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 30 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=481


SomeDude <lovelydear mailmetrash.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lovelydear mailmetrash.com



PDT ---




 This is a very low priority issue.


 
 Well, I don't agree. It's a language design issue, so its priority is higher
 than most implementation matters.


I fully agree with Walter Bright. 

Sorry to be blunt here but this whole discussion is absolutely pointless and
should be closed as WONTFIX right now. People have better things to do.

If some dude can't count the number of elements he puts in his 10 elements
array initializer, he'd better stop programming at all. Introducing some
strange Perl-like syntax for that is madness.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 30 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=481







 Sorry to be blunt here but this whole discussion is absolutely pointless and
 should be closed as WONTFIX right now. People have better things to do.


It's relevant, also because there are 6 votes.



 If some dude can't count the number of elements he puts in his 10 elements
 array initializer, he'd better stop programming at all. Introducing some
 strange Perl-like syntax for that is madness.


Thank you for your note, it allows me to better express why this issue
relevant.

It's not DRY (http://en.wikipedia.org/wiki/DRY ), and duplicated information
tends to get out of sync (and this causes bugs).

You write (think of a as a longer array):

int[5] arr = [1,2,3,4,5];
void main() {}

Later you change the code and your remove on item from the literal, but you
forget to update the array size on the left:

int[5] arr = [1,2,4,5];
void main() {}

The compiler gives you no error nor warning, and arr actually contains
[1,2,4,5,0]. This is a source of bugs, it has happened to me too.

With a syntax like [$] or []S it can't happen, because the length is not stated
twice.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 30 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=481


hsteoh quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh quickfur.ath.cx




[...]

 If some dude can't count the number of elements he puts in his 10 elements
 array initializer, he'd better stop programming at all. Introducing some
 strange Perl-like syntax for that is madness.


You're totally missing the point. Code like this is very prone to bugs:

int[5] x = [1,2,3,4,5];

because as soon as somebody edits the list of elements, the count will be
wrong. Restating something that the compiler already knows is a bad idea. (The
same problem occurs in C/C++; in the C case, depending on the compiler, you may
even get a gratuitous array overrun.)

The proposed int[$] = [ ... ]; is a very good solution, because $ already means
"length of array" in D, and would fit seamlessly into the existing language.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 30 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=481






I agree with the need for some syntactic sugar for static array literal, but is
there any scenario where the postfix literal "auto x=[1,2,3]S" (or [1,2,3]f if
you prefer) proposed in [Issue 8008] doesn't advantageously replace
int[$]x=[1,2,3]? (more generally to force type T in case of ambiguity we can
write [cast(T)1,2,3]S but usually not necessary with 1u,1f etc).

The advantage of [1,2,3]S over [$] or the current situation being that:

1) we can directly pass a static array to a function without requiring an
intermediate static array declaration (int[$]x=[1,2,3]; fun(x); becomes simply
fun([1,2,3]S);

2) from my understanding, there is still an intermediate heap allocation with
the current int[3]=[1,2,3]; please correct me if I'm wrong), which should be
easier to avoid with [1,2,3]S). 

(As an optional bonus, would it also be easy to implement implicit casts with
[...]S ? eg
   void fun(in double[3] x){...}
   fun([1,2,3]S); //should do implicit cast to double[3]; 
   //the implicit casts should follow the same rules as for numeric values. )

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 30 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=481




A bug I've just found. Originally I was using 20 points, and I needed them in a
fixed-size array. Later I have removed some of them to reduce the testing time,
but I have forgotten to update the number of items in P[20].
The compiler gives me no compilation errors (it gives errors only if the number
is less than the number of given items), the missing array items are filled
with P(0,0) by the compiler, the duplicated zero points produce an almost
correct result, but not exactly correct, so I have to spend minutes to spot the
problem. This is the minimized code, that shows this simple bug the compiler
isn't able to find for me:


import std.typecons;
alias Tuple!(int, int) P;
enum P[20] a = [P(62, -67), P(4, -71),   P(-86, 71),  P(-25, -53), P(-23, 70),
                P(46, -34), P(-92, -62), P(-15, 89),  P(100, 42),  P(-4, 43),
                P(21, 59),  P(86, -25),  P(93, -52),  P(-41, -48), P(-45, 76),
                P(85, -43), P(-69, 64)];
void main() {}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 10 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=481


rswhite4 googlemail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rswhite4 googlemail.com



int arr[$] = [1,2,3,4];  // makes an int[4]
Looks pretty nice and I wish something like this often.
Any chance that we get this in the near future (maybe with 2.064)?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 31 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=481


Shriramana Sharma <samjnaa gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |samjnaa gmail.com



PDT ---
FWIW I vote for using int[$] a = [ 1,2,3,4 ] syntax for this. auto[$] would of
course also be valid to allow compile-time type inference.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 31 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=481




See also issue 11156

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 01 2013