In article <ch4fht$2779$1@digitaldaemon.com>, Nick says...
>
>In article <ch4b7u$24sq$1@digitaldaemon.com>, Arcane Jill says...
>>
>>1) It shall be considered a compile-time error for the new use of "length" to eclipse a local variable called "length". (This forces the user to rename their conflicting variable).
>
>"length" might not be a local, it might be a class member or even global, and in some cases you can't change that.

Yes, that's true. But class members can be referenced as "this.length", globals as ".length", and the array length as "<array>.length", so it is always possible to disambiguate in these cases. I don't think that being explicit in the event of ambiguity is a bad thing, given that this is just a convenience syntax.

I can see that container classes might want to define a "length" member, but maybe an opLength() overload would be better anyway, so that this feature can be extended beyond just arrays.



>Personally I don't mind the way it works now,

Nor do I, actually. I'm just thinking aloud.


>but perhaps a special symbol like $ would be safer. (OTOH I don't want my code
>to look like Perl ;-)

I'm with you on all counts there. ($ was my second choice).

Jill

On Wed, 1 Sep 2004 14:20:17 +0200, Bent Rasmussen wrote:

>> e[i...]
>> e[...j]
>> e[i..j]
>>
>> ?
> 
> It means the same as
> 
> e[i...e.length]
> e[0...j]
> 
> I wohn't tell what the last one means. :-)

Notice the three(3) dots, not just two?
I think that Dave was suggesting that instead of e[i..] (with two dots)
that we use e[i...] (with three dots).
-- 
Derek
Melbourne, Australia

> I can see that container classes might want to define a "length" member,
> but
> maybe an opLength() overload would be better anyway, so that this feature
> can be
> extended beyond just arrays.

This may be getting out of hand if we have to introduce an operator to
facilitate this feature/sugar.
Its also not a good thing if sugar one places gives us salt other places, so
to speak.

> Notice the three(3) dots, not just two?

No!

> I think that Dave was suggesting that instead of e[i..] (with two dots)
> that we use e[i...] (with three dots).

I didn't see that before, no. I don't see the point in that though, besides its also subtle.

Bent Rasmussen wrote:

>> I can see that container classes might want to define a "length" member, but maybe an opLength() overload would be better anyway, so that this  feature can be extended beyond just arrays.
> 
> This may be getting out of hand if we have to introduce an operator to facilitate this feature/sugar.
<snip>

What about...

    T[] opSlice(int start = 0, int end = length);

Is there any restriction on what can be a default argument, for that matter?

And similarly, when opSliceAssign finally comes along

    T[] opSliceAssign(T value, int start = 0, int end = length);

Of course, with current restrictions it would be possible to make the begin required and the end optional, but not vice versa.  Even if we don't yet allow the syntax

    opSlice(, 42);

I guess we can support the equivalent with array slices.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

>     T[] opSlice(int start = 0, int end = length);

Interesting. That may be a nice feature. Perhaps even,

int f(int x = g(h)) ...
int g(int x) ...
int h() ...

So it becomes default expressions instead of default values.
In order not to side-track this discussion further, I move on. with haste.
:-)

> I guess we can support the equivalent with array slices.

I don't see why not.

On Wed, 1 Sep 2004 07:49:23 +0000 (UTC), Arcane Jill <Arcane_member@pathlink.com> wrote:
> In article <ch2fml$126h$1@digitaldaemon.com>, antiAlias says...

<snip>

> 1) It shall be considered a compile-time error for the new use of "length" to
> eclipse a local variable called "length". (This forces the user to rename their
> conflicting variable).
>
> 2) Use the symbol "$" instead of the identifier "length". (so
> "e[length-1..length]" becomes "e[$-1..$]"). Note that "$" is a good choice, as
> it already means "end of string" in a regular expression.
>
> 3) Leave things exactly as they are now. If you screw up, it's your problem.
>
> 4) Make "length" a reserved word. This prevents users from having variables of
> this name.
>
> 5) Allow the keyword "with" (or some other keyword) to refer to the array, when
> used within a subscript expression (so "e[length-1..length]" becomes
> "e[with.length-1..with.length]".
>
> 6) Remove the feature altogether

7) Extend the current 'with' to handle all native types, or at least all reference types, (currently it only works on classes) eg.

char[] a;

with(a) {
	printf("%d\n",length);
}

I think we want (1),(6) and (7).

The reasons:
 - 'with' already exists and provides the 'feature' for an existing subset of types.
 - 'with' is more obvious at first glance about what is going on.

I think (3),(4) and (5) are very bad options.
I think (2) is a last resort option.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

>How about a vote?

3 , or just get rid of it altogether.

Charlie.


In article <ch2deu$10tu$1@digitaldaemon.com>, Vathix says...
>
>> > I think it should be an error to declare something with the name length,
>> so
>> > that you catch these mistakes easily. length is a popular name.
>>
>> I was bitten by that in recompiling Phobos, too. But I'm a bit reluctant
>to
>> make it a keyword as it is popular.
>>
>
>I actually don't really like this feature. Allowing with(array) makes more sense to me. It explicitly lets you specify which array you want length to refer to, and it's not just for length.
>
>How about a vote?
>   1) Leave it how it is now; having all these silent bugs and possible
>future misunderstandings.
>   2) Make it an error to declare something with the name 'length'.
>   3) Replace the feature with:  with(array)statement
>
>
>

> Interesting. That may be a nice feature. Perhaps even,
<snip>

Silly me. It allready works that way...

In article <ch4epr$26lu$1@digitaldaemon.com>, Bent Rasmussen says...
>
>> e[i...]
>> e[...j]
>> e[i..j]
>>
>> ?
>
>It means the same as
>
>e[i...e.length]
>e[0...j]
>
>I wohn't tell what the last one means. :-)
>
>

Sorry - didn't see that someone responded to this.

Yes - [i...] would be from i to length. [...j] would be from 0 to j.

I think this is probably 'easy' to parse and lex in that context, and most importantly for me, easy to type <g>!

Plus, the '...' I think is generally accepted as meaning 'from beginning' or 'to end' depending on context, as when paraphrasing.

- Dave