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.

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

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.
>
>

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.

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

"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
>

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

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.

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 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.