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

Thoughts ?

Charlie

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

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

Regan Heath 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
>>
> 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 $?

Or why not just stop with the Perl, and spell it out ? :-)

> import std.stdio;
> void main()
> {
>   char [] x = "comma,";
>   char [] y = x[0 .. x.length-1];
>   writefln(y);
> }

--anders

PS. perl -e 'print substr("comma,", 0, -1) . "\n"'

On Thu, 16 Dec 2004 17:14:51 -0600, Charles wrote:


[snip]

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

I agree. Let's go back to a real language like COBOL.

         ADD WS_NEWVALUE TO WS_VALUE GIVING WS_RESULT.

None of this weirdo symbolic stuff. Let's all just use English words to make ourself perfectly understood ... and start all lines on column 10.

  ;-)

Nah, just joking ... personally I like the '$' symbol used in this context. Its short, not a valid identifier, not used for anything else, and harks back to the commonly used regular expression syntax that means end-of-line.

The other language I use regularly (Euphoria) has just introduced this symbol in its slicing syntax and it is glorious. I knew it would be a nice syntax-sugar-drop, but it suddenly has an uplifting effect in the way one approaches coding. It is no longer a chore to do end-of-slice coding. It fact, you sort of look for ways to use it 'cos its so cool.

-- 
Derek
Melbourne, Australia
17/12/2004 10:28:55 AM

On Fri, 17 Dec 2004 00:14:01 +0100, Anders F Björklund <afb@algonet.se> wrote:
> Regan Heath 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
>>>
>> 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 $?
>
> Or why not just stop with the Perl, and spell it out ? :-)

Personally, I dislike Perl.

>> import std.stdio;
>> void main()
>> {
>>   char [] x = "comma,";
>>   char [] y = x[0 .. x.length-1];
>>   writefln(y);
>> }

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];
}

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.

Also consider multidimensional arrays.

Regan

Regan Heath wrote:

> Personally, I dislike Perl.
> 
[...snip...]
>
> 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.

I like Perl, that has lots of funky chars and ops.
But I kinda like the explicit temp solution too...

So I guess I'm ambivalent about all of it ? :-)
Let's see what Walter says about it, I suppose.

--anders

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

I also had a same idea.

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

It is very simple.

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

On Fri, 17 Dec 2004 12:01:46 +0000 (UTC), k2 wrote:

> I also had a same idea.
> 
> char[] foo = bar[x .. ]; // x to bar.length
> char[] foo = bar[ .. x]; // 0 to x
> 
> It is very simple.
> 
>>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.

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.

-- 
Derek
Melbourne, Australia