On 24/03/2008, Frits van Bommel <fvbommel@remwovexcapss.nl> wrote:
>  > 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:
>  <example of end-relative indexing>

You raise a good point. If we're going to allow

    auto x = 1..3;

then I guess we should also allow

    auto x = 1..$;

Exactly how that should implemented, I'm not sure - but if we get to a solution, it will make ranges mighty powerful beasts!

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?

Yes I have.  The purpose is to implement custom end-relative ranges. The end-relative indexes are represented using a struct like so:

struct EndRelative
{
   int offset;
}

That plus the __opDollar lets you make your user type accept x[3..$-2].

(And even without the opDollar harck you can make it work with something like x[3..end-2].)

--bb

Frits van Bommel wrote:
> 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>) :)

Now we've got renoX's 10th rule!
(Quick renoX -- if you want to be famous, better come up with another 9 rules fast!)

--bb

Janice Caron wrote:
> On 24/03/2008, Frits van Bommel <fvbommel@remwovexcapss.nl> wrote:
>>  > 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:
>>  <example of end-relative indexing>
> 
> You raise a good point. If we're going to allow
> 
>     auto x = 1..3;
> 
> then I guess we should also allow
> 
>     auto x = 1..$;
> 
> Exactly how that should implemented, I'm not sure - but if we get to a
> solution, it will make ranges mighty powerful beasts!

Another very useful thing to have is a notation for the 'everything' slice.   In Python it's just a colon by itself.  It's useful for multi-dimensional arrays:
    x[:3,:]
means slice out rows 0-3 of every column.
Used to good effect in NumPy.

--bb

Bill Baxter wrote:
> Frits van Bommel wrote:
>> 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>) :)
> 
> Now we've got renoX's 10th rule!
> (Quick renoX -- if you want to be famous, better come up with another 9 rules fast!)

No need. (Greenspun didn't have any other rules either :P)

renoX wrote:
> 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?

Definitely not.
Consider floating point ranges. What 'step' do you use?
1..1e10
You can step linearly (1,2,3...), logarithmically(1, 1e2, 1e3...) or in IEEE space. (1, nextUp(1), nextUp(nextUp(1)), ....)
There are just too many reasonable options. Once steps are involved, you need a generator.
But ranges are simple.

On Mon, 24 Mar 2008 14:12:15 +0300, Janice Caron <caron800@googlemail.com> wrote:

> I know this has cropped up before (in discussions about multiple
> dimension arrays), but adding a range type would also really help with
> the whole business of returning slices. (See the many other threads
> currently buzzing with this topic).
>
> A range is nothing more than a two-element struct
>
>     struct Range(T,U=T)
>     {
>         T begin;
>         U end;
>     }
>
> However, if you throw in some extra language support, it gets really,
> really useful. Basically, you want the ".." infix operator always to
> create a range. Thus
>
>     auto x = 3 .. 4;
>
> creates a Range!(int) with values { 3, 4 }. In general (a .. b) should
> evaluate to a Range!(typeof(a),typeof(b)) with values { a, b }.
> Finally, you also want [] and opSlice() to accept Range! parameters,
> so that
>
>     s = s[a..b];
>
> can always be rewritten as
>
>     auto t = a..b;
>     s = s[t];
>
> In general, opSlice(Range r) should be eqivalent to opSlice(r.begin, r.end).
>
> In my opinion language support for ranges (allowing .. to return a
> range, and allowing [] to accept a range) has advantages above and
> beyond those already discussed, and may also allow many other exciting
> possibilites we haven't even thought of yet.

Yeah, built-in Ranges are great! Where do I vote for them? :)