Sam McCall wrote:
> Hmm, you do make a good point.
> Norbert Nemec wrote:
> 
..., we already have a "perfectly functional" Perl ;-)
> A keyword sounds like the answer, three alternatives:
> 1) Make "range" a keyword, and something like foo[2,range-1] would...

> 2) Create a new keyword. Hard to find something short, descriptive, ...  Maybe end?
> 3) Cleverly reuse an existing keyword in an unambiguous way, like "in" 
>...
> 
> [1] could we have
>   foreach(char a in str)
> instead of/in addition to
>   foreach(char a; str)?
> It's not much longer, it's clearer, it doesn't seem to be ambiguous, and it makes it completely obvious that the variable goes first, and the container after.
> 
> Sam
Either "end" or "dim" would get my vote.  "end", because it's the index of the end of the vector, or "dim", because it's the size of the dimension...Note that dim == end + 1.  End is the last element's index, and dim is the count of elements.  This word would be special only within an index...but that would make it a "serious warning" to use it as a variable, and perhaps it should be prohibited.

Range is just too long.  I suppose it's better than doing "arrayFoo[3..arrayFoo.size - 1]", but that leaves a lot of room for improvement.

"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:cchdjc$1gb9$1@digitaldaemon.com...
> Ben Hinkle wrote:
>
> >> I was thinking, if the scope inside [] was the scope of the array, then you could reference it's properties/methods without the name of the array, kinda like the 'with' block/statement does.
> >>
> >> The same sort of rules that apply to 'with' would apply to this.
> >>
> >> eg.
> >>
> >> char[] p;
> >> p[0..length];
> >
> > nifty. I like it. I'm also starting to like "length" in place of "range" to be more like dynamic arrays.
>
> One problem I see: for 1-dimensional arrays, range is of type int[1] while length is of type int - this was the original reason for introducing the new name "range".

oh - I think that's a benefit instead of a problem. :-)
The type "char[]" is distinct from "char[[1]]". The type of the length
property of the former is int and the latter is int[1]. Seems natural to me.

> Furthermore, assignments to "range" are raw-assignments, while assignments to length contain the magic of reallocation.

Yeah - it would be nice to allow code like
  char[[2]] q;
  q.length[0] = 4;
  q.length[1] = 5;
and have it magically allocate space. I'd be willing to live with raw
assignment, though.

> Maybe "range" takes a bit to get used to, but mixing it with the existing "length" property would really be oversimplifying a bit.

could be

> Anyhow: for the problem at hand, "length" might actually do even better!
>
> If we follow that implicit "with" idea, everything would be fine for 1-dim arrays. For N-dim arrays (with N!=1), the ".length" does not exist, so we could do a bit more magic and introduce it within indexing expressions
with
> an automatic index. Ben Hinkles example:
>
> >  char[] p;
> >  p[0..length];
> >  char[[2]] q; // proposed syntax for N-D dynamic arrays
> >  q[0..length[0], 0..length[1]]
>
> would thereby be simplified to:
>
> char[] p;
> p[0..length];
> char[[2]] q; // proposed syntax for N-D dynamic arrays
> q[0..length, 0..length]
>
> Effectivly, length would have become a replacement for the hated $ in the original idea. Intuitively understandable and with clean syntactic and semantic meaning (based on the implicit "with")
>
>

Ben Hinkle wrote:

> 
> "Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:cchdjc$1gb9$1@digitaldaemon.com...
>> Ben Hinkle wrote:
>>
>> >> I was thinking, if the scope inside [] was the scope of the array, then you could reference it's properties/methods without the name of the array, kinda like the 'with' block/statement does.
>> >>
>> >> The same sort of rules that apply to 'with' would apply to this.
>> >>
>> >> eg.
>> >>
>> >> char[] p;
>> >> p[0..length];
>> >
>> > nifty. I like it. I'm also starting to like "length" in place of "range" to be more like dynamic arrays.
>>
>> One problem I see: for 1-dimensional arrays, range is of type int[1] while length is of type int - this was the original reason for introducing the new name "range".
> 
> oh - I think that's a benefit instead of a problem. :-)
> The type "char[]" is distinct from "char[[1]]". The type of the length
> property of the former is int and the latter is int[1]. Seems natural to
> me.

That's another way to see it. Good point. Actually, I chose the name "range" before that split was so clear cut. By now, it might really be obsolete.

> 
>> Furthermore, assignments to "range" are raw-assignments, while assignments to length contain the magic of reallocation.
> 
> Yeah - it would be nice to allow code like
>   char[[2]] q;
>   q.length[0] = 4;
>   q.length[1] = 5;
> and have it magically allocate space. I'd be willing to live with raw
> assignment, though.

How about
        char[[2]] q = new char[4,5];
? I never liked that assignment to .length for one-dimensional arrays too
much, but I'm giving in more and more. Maybe I'll be convinced one day.
There is plenty of time left before N-dim arrays have a chance to really
get into the language, anyway...

In any case: if length were to be a magic assignment, should the language provide raw assignment at all? Or should that be left to brute-force casting methods? Same thing with the .ptr which my proposal still contains. Without raw-writing, the .ptr should probably be dropped completely, since reading can just be done by a simple cast.

Charles Hixson wrote:

> Sam McCall wrote:
>> Hmm, you do make a good point.
>> Norbert Nemec wrote:
>> 
> ..., we already have a "perfectly functional" Perl ;-)
>> A keyword sounds like the answer, three alternatives:
>> 1) Make "range" a keyword, and something like foo[2,range-1] would...
> 
>> 2) Create a new keyword. Hard to find something short, descriptive, ...
>>  Maybe end?
>> 3) Cleverly reuse an existing keyword in an unambiguous way, like "in"
>>...
>> 
>> [1] could we have
>>   foreach(char a in str)
>> instead of/in addition to
>>   foreach(char a; str)?
>> It's not much longer, it's clearer, it doesn't seem to be ambiguous, and
>> it makes it completely obvious that the variable goes first, and the
>> container after.
>> 
>> Sam
> Either "end" or "dim" would get my vote.  "end", because it's the index of the end of the vector, or "dim", because it's the size of the dimension...Note that dim == end + 1.

I actually prefer to use the term "dimension" with respect to the "number of dimension" that a multidimensional array has. Of course, this gets confusion, since a vector in tree-dimensional space would be a one-dimensional array of length 3 in that terminology. Anyhow: this confusion cannot be avoided but is just another sign showing how important a clear terminology is.

I think, the cleanest solution actually is "length" - not very short, but readable, and together with the idea by Regan Heath to make the inside an indexing expression an implicit "with" environment, this fits very cleanly into the language.