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.

"Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.192.1206357352.2351.digitalmars-d@puremagic.com...
>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.

I've actually thought of this before.  IMO, a built-in range type is good fit for D  It also seems like it would be pretty simple to implement.

-Craig

"Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.192.1206357352.2351.digitalmars-d@puremagic.com...
>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;
>    }
>

Why would the type T and U ever be different?  What's the point of the second type being different than the first?

-Craig

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

Janice Caron Wrote:

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

Even if this was just sugar I would vote for it, but being that it could really help with const-ness and thus speed D towards exciting functional paradigms I give it my 100% unconditional support.

And now I need to think whether ranges are the only interesting exceptions to const that we need to consider.

For instance.. CONS? Could we safely make a new const array by concating two constant arrays together? And if so is there any need for this? I can see that it would just another ay of doing COW, but could the compiler apply interesting optimisations (and paralellisations) from this knowledge?

Hmm..

"Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.197.1206370014.2351.digitalmars-d@puremagic.com...
> 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). :-)

Why not just leave out the second type and save some typing?

int.. x;
x = 3 .. 4;

On 24/03/2008, sambeau <sambeau-nospam@mac.com> wrote:
>  And now I need to think whether ranges are the only interesting exceptions to const that we need to consider.

It's not an exception to const.


>  For instance.. CONS? Could we safely make a new const array by concating two constant arrays together? And if so is there any need for this? I can see that it would just another ay of doing COW, but could the compiler apply interesting optimisations (and paralellisations) from this knowledge?

You may perhaps have misunderstood the proposal. The type T..U is sugar for struct { T begin; U end; }, that's all. The value x..y is just an instance of typeof(x)..typeof(y). There's no array magic going on whatsover. You'd use ranges to /slice/ arrays, that's all.

On 24/03/2008, Craig Black <cblack@ara.com> wrote:
> Why not just leave out the second type and save some typing?
>
>  int.. x;

That would make "a..b" semantically ambiguous - is "a.." a type and "b" a value, or is "a..b" an expression?

We need to keep D's grammar context free.

"Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.201.1206373241.2351.digitalmars-d@puremagic.com...
> On 24/03/2008, Craig Black <cblack@ara.com> wrote:
>> Why not just leave out the second type and save some typing?
>>
>>  int.. x;
>
> That would make "a..b" semantically ambiguous - is "a.." a type and "b" a value, or is "a..b" an expression?
>
> We need to keep D's grammar context free.

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

int.. x;   // A range of integers
int[] x;  // An array of integers

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.

That said, it's no big deal. If we're arguing about /syntax/, I guess that mean we're not really disputing the /idea/. So I'm happy to let Walter worry about the syntax.