Janice Caron wrote:
> On 24/03/2008, Craig Black <cblack@ara.com> wrote:
>> I could be wrong, but I don't think this would be a big deal.  The .. would
>>  be interpreted differently when preceded by a type.  The .. would work like
>>  [].
> 
> I don't think it would, because ".." is an infix operator, whereas
> "[]" is a postfix operator.

* is also an infix operator, and we seem to get along fine with that.

Regardless, I don't think it will work. How about if you have an array of ranges?
[10..20, 20..30, 30..40]

How do you write that type?

This doesn't work:
int..int[]
Because, to me anyways, this translates to:
range!(int, int[])


Using .. should work for literals. All that is really needed is changing the precedence of the operator.

Currently, writing this:
x = 0 .. 10
translates to:
(x = 0) .. 10

I think the precedence fits best somewhere between + - and =. This way, we can write both:
x = 0 .. 10
arr[0 .. $ - 1]

Janice Caron a écrit :
> On 24/03/2008, Craig Black <cblack@ara.com> wrote:
>> Why would the type T and U ever be different?  What's the point of the
>>  second type being different than the first?
> 
> Um ... I have no idea. I guess it's just to be consistent with the
> fact that we can already declare:
> 
>     opSlice(T lower, U upper)
> 
> with T and U being different. Maybe someone will find a use for it one
> day. That said, it does at least allow you to use ".." in
> declarations, as in:
> 
>     int..int x;
>     x = 3..4;
> 
> and you have to admit, T..T is likely to be less typing (and look
> prettier) than Range!(T). :-)

Well, most range will probably be integer range, so if we could define
Range! to be Range!(int) by default then it would be even less typing than int..int.

Shouldn't we plan an optional 'step' parameter now?
That said, the 'step' is always messy to add, so having just Range with lower and upper would be a good start.

renoX

PS:
I have the impression that each language grows to reimplement Ada at some point ;-)
(which for me is a good thing!).

On 24/03/2008, Xinok <xnknet@gmail.com> wrote:
>  This doesn't work:
>  int..int[]
>  Because, to me anyways, this translates to:
>  range!(int, int[])

Ah, you're right.

Well then, I guess we'll probably have to call it Range!, with both type parameters beng optional. If both type parameters are omitted, it defaults to size_t (or whatever is considered correct for array indexing these days); if only the second is omitted, the second defaults to the same as the first.

Given that most of the time you're declare it with auto, or infer it from a range expression, that would certainly be acceptable.

"Xinok" <xnknet@gmail.com> wrote in message news:fs8knm$61p$1@digitalmars.com...
> Janice Caron wrote:
>> On 24/03/2008, Craig Black <cblack@ara.com> wrote:
>>> I could be wrong, but I don't think this would be a big deal.  The ..
>>> would
>>>  be interpreted differently when preceded by a type.  The .. would work
>>> like
>>>  [].
>>
>> I don't think it would, because ".." is an infix operator, whereas "[]" is a postfix operator.
>
> * is also an infix operator, and we seem to get along fine with that.
>
> Regardless, I don't think it will work. How about if you have an array of
> ranges?
> [10..20, 20..30, 30..40]
>
> How do you write that type?

int..[]

To clarify my opinion, I don't see a point in specifying the second type.

-Craig

On 24/03/2008, Craig Black <cblack@ara.com> wrote:
> int..[]

I think I'd be happy with Range!(int)


>  To clarify my opinion, I don't see a point in specifying the second type.

...unless of course the second type is different from the first type! :) Rare though that case may be, I think we'd need it in order to retain the existing functionality of opSlice(T,U).

Also, Range!(T,U)[] is unambiguous, wheras T..U[] ...?

"Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.209.1206385654.2351.digitalmars-d@puremagic.com...
> On 24/03/2008, Craig Black <cblack@ara.com> wrote:
>> int..[]
>
> I think I'd be happy with Range!(int)
>
>
>>  To clarify my opinion, I don't see a point in specifying the second
>> type.
>
> ...unless of course the second type is different from the first type! :) Rare though that case may be, I think we'd need it in order to retain the existing functionality of opSlice(T,U).
>
> Also, Range!(T,U)[] is unambiguous, wheras T..U[] ...?

I still think we don't need that second type.  We are talking about D 2.0, so backwards.compatibility is less of an issue.  Unless there's a compelling reason for it, it should be opSlice(T, T).  I think this makes more sense, and simplifies the syntax.

-Craig

> Shouldn't we plan an optional 'step' parameter now?

What would the benefit of the step be?

> That said, the 'step' is always messy to add, so having just Range with lower and upper would be a good start.

I agree that it makes it more messy, and doesn't seem necessary.

-Craig

On 24/03/2008, Craig Black <cblack@ara.com> wrote:
> I still think we don't need that second type.  We are talking about D 2.0,
>  so backwards.compatibility is less of an issue.  Unless there's a compelling
>  reason for it, it should be opSlice(T, T).  I think this makes more sense,
>  and simplifies the syntax.

I agree.

But just to be sure, let's ask the loyal readers of this newsgroup... Has anyone here ever used opSlice(T,U), where type T != type U? And if so, for what purpose, and could you live without it?

Janice Caron wrote:
> On 24/03/2008, Craig Black <cblack@ara.com> wrote:
>> I still think we don't need that second type.  We are talking about D 2.0,
>>  so backwards.compatibility is less of an issue.  Unless there's a compelling
>>  reason for it, it should be opSlice(T, T).  I think this makes more sense,
>>  and simplifies the syntax.
> 
> I agree.
> 
> But just to be sure, let's ask the loyal readers of this newsgroup...
> Has anyone here ever used opSlice(T,U), where type T != type U? And if
> so, for what purpose, and could you live without it?

It could probably be used with something like this:
<http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=67720>

Assuming that code works (I haven't tested it myself) that should allow using $ in user-defined opSlice().
Pretty hack-y though; it seems to depend on a DMDFE implementation detail.

renoX wrote:
> PS:
> I have the impression that each language grows to reimplement Ada at some point ;-)
> (which for me is a good thing!).

Wasn't that Common Lisp? (<http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule>) :)