• ~Gh0sT~ (5/5) May 26 2003 It is a good idea to implement increment and decrement operations for
• Sean L. Palmer (15/20) May 27 2003 There is reasoning behind the current behavior, but I think it's outweig...
• Sean L. Palmer (14/35) May 27 2003 Sorry for the self-reply; I wasn't finished.
• Georg Wrede (7/11) May 27 2003 Ouch?
• ~Gh0sT~ (17/26) May 27 2003 Since the increment are inside the brackets, it is guaranteed that it ha...

~Gh0sT~ <~Gh0sT~_member pathlink.com> writes:

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]

"Sean L. Palmer" <palmer.sean verizon.net> writes:

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]

"Sean L. Palmer" <palmer.sean verizon.net> writes:

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]

Georg Wrede <Georg_member pathlink.com> writes:

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!

~Gh0sT~ <~Gh0sT~_member pathlink.com> writes:

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]