On Sat, Feb 28, 2009 at 1:02 PM, Daniel Keep <daniel.keep.lists@gmail.com>wrote:

>
> Yes, a..b is very nice.  It's also a bad syntax for intervals.  As Don keeps pointing out, you can't have an interval that includes int.max with that syntax.
>


4..$
4u..$
etc?

--bb

Bill Baxter wrote:
> 4..$
> 4u..$
> etc?

Aside from the inconsistent meaning of $, you still can't have an inclusive range [a, b], where 'a' and 'b' are not only known at runtime, without treating 'b == int.max' as a special case.

-- 
Rainer Deyke - rainerd@eldwood.com

Andrei Alexandrescu wrote:
> bearophile wrote:
>> As an alternative syntax may be:
>>
>> foreach (i; 1:10) {...}
>> foreach (i; 10 : 1 : -1) {...}
>> foreach (i; 0.0 : 10.5 : 0.5) {...}
> 
> I have an idea - we define a contextual keyword "iota" that helps us specify from, to, and stride. Then we can write:
> 
> foreach (i; iota(0.0, 10.5, 0.5)) {...}
> 
> 
> Andrei

How about the more intuitive "foreach (i; 0 .. 10.5 stride 0.5)"?

It doesn't always have to be a symbol. ^^

Michel Fortin wrote:
...
> If the language can avoid the clutter in foreach and array slices, then why can't we avoid it elsewhere? Why does an interval when inside a language construct looks better than elsewhere? That's the oddities mapping a..b to a standard type usable everywhere would avoid.

It would be more consistent and nice if a..b would work everywhere without problems, but imho inter(a,b) is not that much clutter. Especially when strides come into play, I think stride(range, x) is much more readable than adding even more operators.

What would really make ranges more readable is extension methods to get rid of all the nesting. After two of three levels of nesting it's starts to get quite annoying. Reading from left to right is just more natural than from the inside out.

Daniel Keep wrote:
> Yes, a..b is very nice.  It's also a bad syntax for intervals.  As Don keeps pointing out, you can't have an interval that includes int.max with that syntax.

4 .. int.$

—Joel Salomon

Joel C. Salomon wrote:
> Daniel Keep wrote:
>> Yes, a..b is very nice.  It's also a bad syntax for intervals.  As Don
>> keeps pointing out, you can't have an interval that includes int.max
>> with that syntax.
> 
> 4 .. int.$
> 
> —Joel Salomon

I love that real.$ is the number that's even bigger than infinity <g>.
What if the range is stored in variables?

x[a..b];
How can you set b so that it includes x[int.max]?

BTW, I'm not merely being negative, I'd love for one of these schemes to work.

On Tue, Mar 3, 2009 at 5:22 PM, Don <nospam@nospam.com> wrote:
> Joel C. Salomon wrote:
>>
>> Daniel Keep wrote:
>>>
>>> Yes, a..b is very nice.  It's also a bad syntax for intervals.  As Don keeps pointing out, you can't have an interval that includes int.max with that syntax.
>>
>> 4 .. int.$
>>
>> —Joel Salomon
>
> I love that real.$ is the number that's even bigger than infinity <g>. What if the range is stored in variables?
>
> x[a..b];
> How can you set b so that it includes x[int.max]?

How about x[a..b] vs x[a..b+] ?

On Tue, 03 Mar 2009 19:37:13 +0300, Tomas Lindquist Olsen <tomas.l.olsen@gmail.com> wrote:

> On Tue, Mar 3, 2009 at 5:22 PM, Don <nospam@nospam.com> wrote:
>> Joel C. Salomon wrote:
>>>
>>> Daniel Keep wrote:
>>>>
>>>> Yes, a..b is very nice.  It's also a bad syntax for intervals.  As Don
>>>> keeps pointing out, you can't have an interval that includes int.max
>>>> with that syntax.
>>>
>>> 4 .. int.$
>>>
>>> —Joel Salomon
>>
>> I love that real.$ is the number that's even bigger than infinity <g>.
>> What if the range is stored in variables?
>>
>> x[a..b];
>> How can you set b so that it includes x[int.max]?
>
> How about x[a..b] vs x[a..b+] ?

What would the signature of opSlice be in both case? Or different methods invoked?