Linux:  Digital Mars D Compiler v0.123

I came across an unexpected conflict between a local "length" variable and an internal one referring to an array size.  The following code demonstrates the problem:

ubyte[] foo(void* x, uint length)
{
  ubyte*  a = cast(ubyte*)x;
  ubyte[] b;
  b[0..length] = a[0..length];
  return b;
}

int main(char[][] args)
{
  char[] a = "abc";
  ubyte[] b;

  b = foo(a,3);
  printf("%.*s\n",b);
}

anchorage:~/tmp> dmd test.d && ./test
gcc test.o -o test -lphobos -lpthread -lm
Error: lengths don't match for array copy


It seems that "length" when used within the context of an array subscript takes on the length of the array instead of the value of the local variable.

As far as I can tell, this goes against D's basic design goals.  Since one is not allowed to even redefine a variable in a sub-block ("A block statement introduces a new scope for local symbols. A local symbol's name, however, must be unique within the function." [http://www.digitalmars.com/d/statement.html#block]), it seems unreasonable to have the compiler override an explicit local variable with an implicit internal one.

                                          Brian
                                 ( bcwhite@precidia.com )

-------------------------------------------------------------------------------
               Computers make very fast, very accurate mistakes.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian White schrieb am Tue, 17 May 2005 09:19:30 -0400:

<snip>

> It seems that "length" when used within the context of an array subscript takes on the length of the array instead of the value of the local variable.
>
> As far as I can tell, this goes against D's basic design goals.

<snip>

Use the dollar sign ($) to access the array's length inside it's subscript and don't declare a "length" identifier in your code.

The implicit "length" inside the subscript is scheduled for potential deprecation.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCihNB3w+/yD4P9tIRAnyvAJ41QYqKWZTNLvHFqtrhfYWkbsauZgCeJ6YR
HJ4FwcsKye+SrETXgRZZmuo=
=3nv9
-----END PGP SIGNATURE-----

>>It seems that "length" when used within the context of an array subscript takes on the length of the array instead of the value of the local variable.
>>
>>As far as I can tell, this goes against D's basic design goals.
> 
> Use the dollar sign ($) to access the array's length inside it's
> subscript and don't declare a "length" identifier in your code.
> 
> The implicit "length" inside the subscript is scheduled for potential deprecation.

Great!  That's what I was getting at...  The implicit "length" is going to cause confusion to a lot of people; it's a natural variable name to use.

                                          Brian
                                 ( bcwhite@precidia.com )

-------------------------------------------------------------------------------
Idleness, indifference & irresponsibility are healthy responses to absurd work.

> Great!  That's what I was getting at...  The implicit "length" is going to cause confusion to a lot of people; it's a natural variable name to
use.

I agree, Im glad there taking it out :).

Charlie


"Brian White" <bcwhite@precidia.com> wrote in message news:d6d1cs$3fv$1@digitaldaemon.com...
> >>It seems that "length" when used within the context of an array subscript takes on the length of the array instead of the value of the local variable.
> >>
> >>As far as I can tell, this goes against D's basic design goals.
> >
> > Use the dollar sign ($) to access the array's length inside it's subscript and don't declare a "length" identifier in your code.
> >
> > The implicit "length" inside the subscript is scheduled for potential deprecation.
>
> Great!  That's what I was getting at...  The implicit "length" is going to cause confusion to a lot of people; it's a natural variable name to
use.
>
>                                            Brian
>                                   ( bcwhite@precidia.com )
>
> --------------------------------------------------------------------------
-----
> Idleness, indifference & irresponsibility are healthy responses to absurd work.