Thread overview
'array.length is not an lvalue' message
May 26, 2003
~Gh0sT~
May 27, 2003
Sean L. Palmer
May 27, 2003
Sean L. Palmer
May 27, 2003
Georg Wrede
May 27, 2003
~Gh0sT~
May 26, 2003
It is a good idea to implement increment and decrement operations for
array.length property.
Construction '++ array.length' are simply to read than 'array.length =
array.length + 1'.

~Gh0sT~ [frankenstein@fastmail.fm]
May 27, 2003
There is reasoning behind the current behavior, but I think it's outweighed by the need for the language to be orthogonal;  there shouldn't be silly special cases like this.

One good reason is that:

array[array.length++] = foo;

is not guaranteed to produce any meaningful result because the language doesn't specify when exactly the ++ happens.  Certainly doesn't currently (although it would be straightforward to make it work) provide any guarantee that the array dereference will happen after the ++.

One easy way would be for *all* operations inside square brackets be evaluated fully before any operations outside the square brackets can be evaluated.  So it evaluates inside out.

Sean

"~Gh0sT~" <~Gh0sT~_member@pathlink.com> wrote in message news:batlkn$2487$1@digitaldaemon.com...
> It is a good idea to implement increment and decrement operations for
> array.length property.
> Construction '++ array.length' are simply to read than 'array.length =
> array.length + 1'.
>
> ~Gh0sT~ [frankenstein@fastmail.fm]


May 27, 2003
Sorry for the self-reply;  I wasn't finished.

But the main point is that, just because a language feature is a little confusing for beginners or has the possibility of someone shooting themselves in the foot, doesn't mean that feature needs crippled or made into an exceptional case.  That's just going to add to the confusion for beginners, and pros will think it's limiting and annoying.

Special cases are, in general, bad.  It would be great if I could someday scan the D Programming Language website and find 0 occurrences of the word "exception" that weren't talking about error handling.

Sean


"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bav944$jih$1@digitaldaemon.com...
> There is reasoning behind the current behavior, but I think it's
outweighed
> by the need for the language to be orthogonal;  there shouldn't be silly special cases like this.
>
> One good reason is that:
>
> array[array.length++] = foo;
>
> is not guaranteed to produce any meaningful result because the language doesn't specify when exactly the ++ happens.  Certainly doesn't currently (although it would be straightforward to make it work) provide any
guarantee
> that the array dereference will happen after the ++.
>
> One easy way would be for *all* operations inside square brackets be evaluated fully before any operations outside the square brackets can be evaluated.  So it evaluates inside out.
>
> Sean
>
> "~Gh0sT~" <~Gh0sT~_member@pathlink.com> wrote in message news:batlkn$2487$1@digitaldaemon.com...
> > It is a good idea to implement increment and decrement operations for
> > array.length property.
> > Construction '++ array.length' are simply to read than 'array.length =
> > array.length + 1'.
> >
> > ~Gh0sT~ [frankenstein@fastmail.fm]
>
>


May 27, 2003
In article <bav944$jih$1@digitaldaemon.com>, Sean L. Palmer says...
>
>array[array.length++] = foo;
..
>One easy way would be for *all* operations inside square brackets be evaluated fully before any operations outside the square brackets can be evaluated.  So it evaluates inside out.

Ouch?

And I took it for granted that the inside of square brackets is _always_ evaluated before the outside in D! If we are going to have a "no catches" language, especially for people without a heavy C(++) background, then this is essential!


May 27, 2003
In article <bav944$jih$1@digitaldaemon.com>, Sean L. Palmer says...
>
>One good reason is that:
>array[array.length++] = foo;
>is not guaranteed to produce any meaningful result because the language
>doesn't specify when exactly the ++ happens.  Certainly doesn't currently
>(although it would be straightforward to make it work) provide any guarantee
>that the array dereference will happen after the ++.
>
>One easy way would be for *all* operations inside square brackets be evaluated fully before any operations outside the square brackets can be evaluated.  So it evaluates inside out.
>

Since the increment are inside the brackets, it is guaranteed that it happens before the defeference.

And... will be good to make all possible ariphmetic operators work with 'array.length' property.

I've confused by this strings:
astruct.asubstruct.aarray[n]
= astruct.asubstruct.aarray
[astruct.asubstruct.aarray.length - 1];
astruct.asubstruct.aarray.length
= astruct.asubstruct.aarray.length - 1;

It is too easy to write:
with( astruct.asubstruct )
aarray[n] = aarray[aarray.length --];

AND THEREFORE 'WITH' KEYWORD WILL WORK FOR STRUCTURES AND TEMPLATES.


~Gh0sT~

~Gh0sT~ [frankenstein@fastmail.fm]