>> I also had a same idea.
>>
>> char[] foo = bar[x .. ]; // x to bar.length
>> char[] foo = bar[ .. x]; // 0 to x

I actually meant it with 3 dots, because it already exists as a 'something without end' notation in the language. But your 2-dot version would be good against Derek's argument:

>>>char [] y = x[0...];
>
> Unfortunately this syntax is slightly ambiguous. It could mean that the
> coder has left something off. The compiler can no longer tell if you
> simply
> forgot something or not. Too easy to make that mistake, IMHO.

Hmmm. I wonder if this reasoning can be applied to other constructions in D (or C for that matter).

The double-dot ".." would be a good candidate then, since for it to be ambigous, the programmer would have to forget a dot and an expression in that case, which has a much smaller chance of occuring.

Lionello.

Only problem with this is you can specify an offset from the end of the array :(.

Charlie

"Lionello Lunesu" <lionello.lunesu@crystalinter.remove.com> wrote in message news:cpu384$1dgu$1@digitaldaemon.com...
> > char [] y = x[0 .. -1]; // y is 'comma'
> >
> >
> > No special charaters , no new keywords , no scoping rules ( is length
> > still
> > a keyword in slicing ? ).
> >
> > Thoughts ?
>
> What about
>
> char [] y = x[0...];
>
> No keywords, and it can't possibly be interpreted any other way. No way to slice up to next-to-last element though.
>
> Lionello.
>
>

Actually I don't see the case for C/C++ , could anyone provide an example where this behaviour is defined and reliable ?

Thanks,
Charlie

p.s. Anyone read imperfect C++ ( matthew's book ) ? I read a good review about but haven't been able to find it at my local bookstores, will have to order it :S.


"Charles" <no@email.com> wrote in message news:cpt4r1$epb$1@digitaldaemon.com...
> > "that array subscripting in C and C++ and D can be done with signed integers because it is legal _and meaningful_ to pass a -ve subscript to mean prior to the given base (pointer and/or array)." - Matthew
>
> Hmm , could i get an example of how this would be useful in D's arrays ? Pointer's I can understand , and i could see the case for C/C++ , but for
D
> ?  Seems a big sacrifice for backward compatibility .
>
> > The problem with length is that it can conflict with global/local and other variables.
>
> I agree, especially since length is such a commonly used variable name.
>
> > So perhaps it's time to revisit the idea of using $?
>
> I dislike special charaters ( just my own feelings ) , visibly seems unappealing - breaks the consistency of the language, though I think its better than 'length'.
>
> Charlie
>
> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsi4ieib023k2f5@ally...
> > On Thu, 16 Dec 2004 16:45:09 -0600, Charles <no@email.com> wrote:
> > > This has probably already been mentioned , and I know D's not
> > > implementing
> > > new features , but what about using negative numbers to indicate
> starting
> > > from the end of the array
> > >
> > > char [] x = "comma,";
> > >
> > > char [] y = x[0 .. -1]; // y is 'comma'
> > >
> > >
> > > No special charaters , no new keywords , no scoping rules ( is length
> > > still a keyword in slicing ? ).
> >
> > I believe so, however I think it was decided it was not a GoodThing(TM).
> >
> > > Thoughts ?
> >
> > It has been mentioned before, the problem with it is:
> >
> > "that array subscripting in C and C++ and D can be done with signed integers because it is legal _and meaningful_ to pass a -ve subscript to mean prior to the given base (pointer and/or array)." - Matthew
> >
> > Another suggestion was to have a character or symbol to mean the end of the array, for example:
> >
> > char[] y = x[0..$-1];
> >
> > so $ means the length of the array.
> >
> > Instead of '$', 'length' was decided upon and used.
> > The problem with length is that it can conflict with global/local and
> > other variables.
> >
> > So perhaps it's time to revisit the idea of using $?
> >
> > Regan
>
>

In article <cq07t2$jbn$1@digitaldaemon.com>, Charles says...
>
>p.s. Anyone read imperfect C++ ( matthew's book ) ? I read a good review about but haven't been able to find it at my local bookstores, will have to order it :S.

I went to the best Computer Bookstore in Helsinki (, Finland), and they not only were familiar with the book, but they had sold out the first shipment in just a couple of days. I'm on the list.

Looks like the per-hour-invested-writing rate will be "adequate" for Matthew, at least with this book!

Congratulations!!

In article <cpuquc$29lb$1@digitaldaemon.com>, Lionello Lunesu says...
>
>>> I also had a same idea.
>>>
>>> char[] foo = bar[x .. ]; // x to bar.length

Too near "char[] foo = bar[x .. $]; // ..."

>>> char[] foo = bar[ .. x]; // 0 to x

Too near "char [] foo = bar[0..X] // ..."

This of course assuming we are going to get a "$" operator as in Euphoria.



>I actually meant it with 3 dots, because it already exists as a 'something without end' notation in the language. But your 2-dot version would be good against Derek's argument:
>
>>>>char [] y = x[0...];
>>
>> Unfortunately this syntax is slightly ambiguous. It could mean that the
>> coder has left something off. The compiler can no longer tell if you
>> simply
>> forgot something or not. Too easy to make that mistake, IMHO.
>
>Hmmm. I wonder if this reasoning can be applied to other constructions in D (or C for that matter).
>
>The double-dot ".." would be a good candidate then, since for it to be ambigous, the programmer would have to forget a dot and an expression in that case, which has a much smaller chance of occuring.
>
>Lionello.
>
>

On Fri, 17 Dec 2004 12:56:32 +1300, Regan Heath <regan@netwin.co.nz> wrote:

<snip>
> Because this:
>
> void main()
> {
> 	Foo f = new Foo();
>        char[] y;
>
> 	y = f.longishStructureName.alsoKindaLongVariable[0..f.longishStructureName.alsoKindaLongVariable.length-1];
> }
>
> is not as nice as:
>
> void main()
> {
> 	Foo f = new Foo();
>        char[] y;
>
> 	y = f.longishStructureName.alsoKindaLongVariable[0..$-1];
> }

You do know you can just type
	f.longishStructureName.alsoKindaLongVariable[0..length-1];
right? Or is that what you meant with your next statement?

> One of the reasons "length" was added, also an array returned by a function:
>
> void main()
> {
> 	char[] y = foo()[0..$-1]
> }
>
> is nicer than:
>
> void main()
> {
> 	char[] temp = foo();
> 	char[] y = temp[0..temp.length-1]
> }
>
> assuming foo() can be evaluated only once.

As far as I am aware, they both compile, ($ for length, of course)
and to the same instructions (except for the extra var, of course)

> Also consider multidimensional arrays.

A valid point, but the way they are currently done, you should be able to type
	foo[5][][17][][] reallyBigMultiArray;
	...
	reallyBigMultiArray[length][3][14][length-3] = someFooArrayOfFiveFunction();

and it will pick the current subscript's scope's length, But I haven't tested it yet.

> Regan



-- 
"Unhappy Microsoft customers have a funny way of becoming Linux,
Salesforce.com and Oracle customers." - www.microsoft-watch.com:
"The Year in Review: Microsoft Opens Up"
--
"I plan on at least one critical patch every month, and I haven't been disappointed."
- Adam Hansen, manager of security at Sonnenschein Nath & Rosenthal LLP
(Quote from http://www.eweek.com/article2/0,1759,1736104,00.asp)
--
"It's been a challenge to "reteach or retrain" Web users to pay for content, said Pizey"
-Wired website: "The Incredible Shrinking Comic"

On Sun, 19 Dec 2004 20:56:30 +1300, Simon Buchan <currently@no.where> wrote:
> On Fri, 17 Dec 2004 12:56:32 +1300, Regan Heath <regan@netwin.co.nz> wrote:
>
> <snip>
>> Because this:
>>
>> void main()
>> {
>> 	Foo f = new Foo();
>>        char[] y;
>>
>> 	y = f.longishStructureName.alsoKindaLongVariable[0..f.longishStructureName.alsoKindaLongVariable.length-1];
>> }
>>
>> is not as nice as:
>>
>> void main()
>> {
>> 	Foo f = new Foo();
>>        char[] y;
>>
>> 	y = f.longishStructureName.alsoKindaLongVariable[0..$-1];
>> }
>
> You do know you can just type
> 	f.longishStructureName.alsoKindaLongVariable[0..length-1];
> right? Or is that what you meant with your next statement?

Yes.

>> One of the reasons "length" was added, also an array returned by a function:
>>
>> void main()
>> {
>> 	char[] y = foo()[0..$-1]
>> }
>>
>> is nicer than:
>>
>> void main()
>> {
>> 	char[] temp = foo();
>> 	char[] y = temp[0..temp.length-1]
>> }
>>
>> assuming foo() can be evaluated only once.
>
> As far as I am aware, they both compile, ($ for length, of course)
> and to the same instructions (except for the extra var, of course)

I had hoped they would. I realised this is only syntactical sugar however I believe it increases readability.

>> Also consider multidimensional arrays.
>
> A valid point, but the way they are currently done, you should be able to type
> 	foo[5][][17][][] reallyBigMultiArray;
> 	...
> 	reallyBigMultiArray[length][3][14][length-3] = someFooArrayOfFiveFunction();
>
> and it will pick the current subscript's scope's length, But I haven't tested it yet.

Exactly. It was my impression also that it should work, I haven't tested it yet either :)

Regan

Yea my local bookstores dont carry any good technical books , but im asking for it for christmas :).

> Congratulations!!

Second that :)

Charlie
"Georg Wrede" <Georg_member@pathlink.com> wrote in message
news:cq2kf8$2q4a$1@digitaldaemon.com...
> In article <cq07t2$jbn$1@digitaldaemon.com>, Charles says...
> >
> >p.s. Anyone read imperfect C++ ( matthew's book ) ? I read a good review about but haven't been able to find it at my local bookstores, will have
to
> >order it :S.
>
> I went to the best Computer Bookstore in Helsinki (, Finland), and they not only were familiar with the book, but they had sold out the first shipment in just a couple of days. I'm on the list.
>
> Looks like the per-hour-invested-writing rate will be "adequate" for Matthew, at least with this book!
>
> Congratulations!!
>
>