• Vathix (15/15) Apr 12 2003 None of this is necessary but might be good for convenience:
• J C Calvarese (13/33) Apr 13 2003 I'm with you. I've been annoyed with each of those issues. I suspect
• anderson (12/45) Apr 17 2003 operators
• J C Calvarese (8/38) Apr 17 2003 Thanks for the background (yeah precedence order would be a problem in
• Matthew Wilson (6/21) Apr 13 2003 I agree with 3 certainly.
• Sean L. Palmer (21/45) Apr 13 2003 1) was because that style is considered sloppy memory management. Howev...
• J C Calvarese (16/21) Apr 13 2003 That's a certainly valid point.
• Vathix (3/3) Apr 18 2003 Since I think runtime bounds checking is only for -debug, I don't see wh...
• Burton Radons (11/27) Apr 21 2003 This didn't get described correctly. It's because of "a [a.length ++] =...
• Burton Radons (2/6) Apr 21 2003 Whoops, this is exactly what DMD does now, so I'm happy with the status ...
• Sean L. Palmer (15/26) Apr 22 2003 Am I correct in saying that the problem is that we can't know if postfix...

"Vathix" <Vathix kernel.net> writes:

None of this is necessary but might be good for convenience:

1)
Why can't I use ++, += etc on a dynamic array's .length?  Those operators
are for typing less, so why can't I be lazy with this too?  :+)

2)
I think it would be handy to allow concating a single object to an array
with ~.
e.g.  arrayObject ~ singleObject

3)
Would it really be considered going out of bounds if you were slicing an
array of 0 elements past the last element (or before the first)?  It
shouldn't even access the memory at the location so I think it should be
allowed.
e.g.  myObj[0 .. i] ~ myObj[i + 1 .. myObj.length]
If I wanted to remove the i'th object and i + 1 was the end.

J C Calvarese <jcc-47 excite.com> writes:

I'm with you.  I've been annoyed with each of those issues.  I suspect 
there's a reason for each, but they still bug me.

Vathix wrote:
 None of this is necessary but might be good for convenience:
 
 1)
 Why can't I use ++, += etc on a dynamic array's .length?  Those operators
 are for typing less, so why can't I be lazy with this too?  :+)

Somebody wrote before why this was prohibited, but I don't remember 
quite what it was.  It seemed like it was to keep us from shooting 
ourselves in the foot with things like:
s[s.length++] = "whatever";
but I don't remember what's so bad about that...

 
 2)
 I think it would be handy to allow concating a single object to an array
 with ~.
 e.g.  arrayObject ~ singleObject

Yeah, sometimes it'd be very convenient to concatenate a fixed-length 
string and a variable-length string, too.

 
 3)
 Would it really be considered going out of bounds if you were slicing an
 array of 0 elements past the last element (or before the first)?  It
 shouldn't even access the memory at the location so I think it should be
 allowed.
 e.g.  myObj[0 .. i] ~ myObj[i + 1 .. myObj.length]
 If I wanted to remove the i'th object and i + 1 was the end.
 
 

It'd suit me fine if you had a five element array and s[7..100] just 
yielded an empty set.  "Error: Access Violation" grates on my nerves. :)

Justin

"anderson" <anderson badmama.com.au> writes:

"J C Calvarese" <jcc-47 excite.com> wrote in message
news:b7b4l8$191j$1 digitaldaemon.com...
 I'm with you.  I've been annoyed with each of those issues.  I suspect
 there's a reason for each, but they still bug me.

 Vathix wrote:
 None of this is necessary but might be good for convenience:

 1)
 Why can't I use ++, += etc on a dynamic array's .length?  Those


operators
 are for typing less, so why can't I be lazy with this too?  :+)

 Somebody wrote before why this was prohibited, but I don't remember
 quite what it was.  It seemed like it was to keep us from shooting
 ourselves in the foot with things like:
 s[s.length++] = "whatever";
 but I don't remember what's so bad about that...

As I remember, it was a memory management thing because Walter was tring to
protect people from writing loops using array++ within.  We went into large
discussions about memory blocks ect... and other techniques in an attempt to
find some solution.  It was eventually decided against because apparently it
was to hard to come up with something optiminal for all (most) cases.

Anyhow, a point was also brought up about "s[s.length++] = "whatever";" was:
What is the precidence order?

Anyhow you can use,

s ~= "whatever";

 2)
 I think it would be handy to allow concating a single object to an array
 with ~.
 e.g.  arrayObject ~ singleObject

 Yeah, sometimes it'd be very convenient to concatenate a fixed-length
 string and a variable-length string, too.

 3)
 Would it really be considered going out of bounds if you were slicing an
 array of 0 elements past the last element (or before the first)?  It
 shouldn't even access the memory at the location so I think it should be
 allowed.
 e.g.  myObj[0 .. i] ~ myObj[i + 1 .. myObj.length]
 If I wanted to remove the i'th object and i + 1 was the end.

 It'd suit me fine if you had a five element array and s[7..100] just
 yielded an empty set.  "Error: Access Violation" grates on my nerves. :)

 Justin

J C Calvarese <jcc7 cox.net> writes:

Comments below...

anderson wrote:
 "J C Calvarese" <jcc-47 excite.com> wrote in message
 news:b7b4l8$191j$1 digitaldaemon.com...
1)
Why can't I use ++, += etc on a dynamic array's .length?  Those


 
 operators
 
are for typing less, so why can't I be lazy with this too?  :+)

Somebody wrote before why this was prohibited, but I don't remember
quite what it was.  It seemed like it was to keep us from shooting
ourselves in the foot with things like:
s[s.length++] = "whatever";
but I don't remember what's so bad about that...

 
 
 As I remember, it was a memory management thing because Walter was tring to
 protect people from writing loops using array++ within.  We went into large
 discussions about memory blocks ect... and other techniques in an attempt to
 find some solution.  It was eventually decided against because apparently it
 was to hard to come up with something optiminal for all (most) cases.
 
 Anyhow, a point was also brought up about "s[s.length++] = "whatever";" was:
 What is the precidence order?
 
 Anyhow you can use,
 
 s ~= "whatever";
 
 

Thanks for the background (yeah precedence order would be a problem in 
that case).  I'd like to be able to just type: "s.length++;" to increase 
  the elements in the array, but oh well.  (I'll promise not to use put 
it in brackets if that would help.)

Thanks for the ~= hint.  I'll try use it to my advantage.

Justin

"Matthew Wilson" <dmd synesis.com.au> writes:

I agree with 3 certainly.

I do recall that there were compelling reasons against 1, but cannot
remember what (sorry).

No opinion as yet on 2

"Vathix" <Vathix kernel.net> wrote in message
news:b7aqi4$12o6$1 digitaldaemon.com...
 None of this is necessary but might be good for convenience:

 1)
 Why can't I use ++, += etc on a dynamic array's .length?  Those operators
 are for typing less, so why can't I be lazy with this too?  :+)

 2)
 I think it would be handy to allow concating a single object to an array
 with ~.
 e.g.  arrayObject ~ singleObject

 3)
 Would it really be considered going out of bounds if you were slicing an
 array of 0 elements past the last element (or before the first)?  It
 shouldn't even access the memory at the location so I think it should be
 allowed.
 e.g.  myObj[0 .. i] ~ myObj[i + 1 .. myObj.length]
 If I wanted to remove the i'th object and i + 1 was the end.

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

1) was because that style is considered sloppy memory management.  However I
don't see the problem if the array properly reserved enough space before you
start.  I believe that a language shouldn't prevent someone from writing
sloppy code because if it does it'll also inadvertently prevent someone from
writing truly creative genius code.  Besides performance isn't always the
top issue.  I think it'd be convenient and that convenience merits
inclusion.  If you cannot currently reserve space for an array, perhaps you
should be able to.  Or maybe D needs some kind of "array constructor helper"
object which manages an array that is in process of being built, and
maintains the reserved space etc, and frees up any extra space when the
array is finished being built.

2) I think this should be allowed for much the same reason as 1).

3)  I disagree with you guys because it would require more runtime bounds
checks to do that.  Every slice would require the extra bounds checks.  If
you want a language that won't ever give you a GPF then you are going to
have to live with the performance of Java or some other heavyweight
language.

Sean

"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:b7bbul$1ctk$1 digitaldaemon.com...
 I agree with 3 certainly.

 I do recall that there were compelling reasons against 1, but cannot
 remember what (sorry).

 No opinion as yet on 2

 "Vathix" <Vathix kernel.net> wrote in message
 news:b7aqi4$12o6$1 digitaldaemon.com...
 None of this is necessary but might be good for convenience:

 1)
 Why can't I use ++, += etc on a dynamic array's .length?  Those


operators
 are for typing less, so why can't I be lazy with this too?  :+)

 2)
 I think it would be handy to allow concating a single object to an array
 with ~.
 e.g.  arrayObject ~ singleObject

 3)
 Would it really be considered going out of bounds if you were slicing an
 array of 0 elements past the last element (or before the first)?  It
 shouldn't even access the memory at the location so I think it should be
 allowed.
 e.g.  myObj[0 .. i] ~ myObj[i + 1 .. myObj.length]
 If I wanted to remove the i'th object and i + 1 was the end.

J C Calvarese <jcc-47 excite.com> writes:

Thanks for the explanations.

Sean L. Palmer wrote:
 3)  I disagree with you guys because it would require more runtime bounds
 checks to do that.  Every slice would require the extra bounds checks.  If
 you want a language that won't ever give you a GPF then you are going to
 have to live with the performance of Java or some other heavyweight
 language.

That's a certainly valid point.

I understand that a certain responsibility will have to fall on the 
programmer in order to keep the possibility of light and fast programs 
around, but it seems to me that every time I do a slice, I have to check 
the length first.  I guess you and others are writing code where they 
sometimes know they're not slicing out of bound, but when I need to 
write code to check the length every time I wonder if this is a job 
better handled by the compiler itself.  Perhaps as my programming 
techniques improve, I won't need to check nearly as often.  At that 
point I would completely agree with you.

I don't want the compiler doing so many runtime checks that the code is 
bloated either.  But if the same check is called for every time anyways, 
I'd prefer to let the compiler take care of it.

Justin

"Vathix" <Vathix kernel.net> writes:

Since I think runtime bounds checking is only for -debug, I don't see why it
would be so hard to determine 0 elements and allow it.  As for -release, it
wouldn't even be a problem since it shouldn't access the 0 elements.

Burton Radons <loth users.sourceforge.net> writes:

Vathix wrote:

 None of this is necessary but might be good for convenience:
 
 1)
 Why can't I use ++, += etc on a dynamic array's .length?  Those operators
 are for typing less, so why can't I be lazy with this too?  :+)

This didn't get described correctly.  It's because of "a [a.length ++] = 
4", which is an undefined expression.  Like the ban on "if (a = b)", I 
think it's addressed at the wrong level; it should identify this 
easy-to-write and incorrect code in the semantic level, rather than 
having a catch-all that grabs many benign uses of .length.

 2)
 I think it would be handy to allow concating a single object to an array
 with ~.
 e.g.  arrayObject ~ singleObject

Yeah, the inconsistency between ~= and ~ is a flaw.

 3)
 Would it really be considered going out of bounds if you were slicing an
 array of 0 elements past the last element (or before the first)?  It
 shouldn't even access the memory at the location so I think it should be
 allowed.
 e.g.  myObj[0 .. i] ~ myObj[i + 1 .. myObj.length]
 If I wanted to remove the i'th object and i + 1 was the end.

I second a subset of this - the debug test for slicing is incorrect; it 
should be "start <= length" rather than "start < length".  Zero-length 
slices of out-of-range values are just wrong, and your code right there 
wouldn't allow it anyway (out-of-range "i" results in negative slices).

Burton Radons <loth users.sourceforge.net> writes:

Burton Radons wrote:
 I second a subset of this - the debug test for slicing is incorrect; it 
 should be "start <= length" rather than "start < length".  Zero-length 
 slices of out-of-range values are just wrong, and your code right there 
 wouldn't allow it anyway (out-of-range "i" results in negative slices).

Whoops, this is exactly what DMD does now, so I'm happy with the status quo.

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

Am I correct in saying that the problem is that we can't know if postfix++
happens before or after the assignment, which depends on the ++ executing
before the assignment, or it'll store into invalid memory?

// a [a.length ++] = 4;  // bad

This seems to be a sort of reverse argument for defining when postfix ++
happens better.  Instead of just "before the next sequence point" define it
to be "before any expression which uses the result of the x++ is evaluated".
At least for arguments which aren't simple integers, such as a.length, where
incrementing has side effects.

C is so imprecise.  D doesn't have to be.  The result:  more portable code
for everybody.

Sean

"Burton Radons" <loth users.sourceforge.net> wrote in message
news:b82ja0$hdf$1 digitaldaemon.com...
 Vathix wrote:

 None of this is necessary but might be good for convenience:

 1)
 Why can't I use ++, += etc on a dynamic array's .length?  Those


operators
 are for typing less, so why can't I be lazy with this too?  :+)

 This didn't get described correctly.  It's because of "a [a.length ++] =
 4", which is an undefined expression.  Like the ban on "if (a = b)", I
 think it's addressed at the wrong level; it should identify this
 easy-to-write and incorrect code in the semantic level, rather than
 having a catch-all that grabs many benign uses of .length.