First class lazy Interval

[Daniel Keep]

Michel Fortin wrote:
> On 2009-02-27 09:47:30 -0500, Daniel Keep <daniel.keep.lists at gmail.com>
> said:
> 
>>> assert(index in 0.._size);
>>
>> I don't think this should be in the language... it just feels like there
>> isn't enough use for it.  Especially not when you can implement it as a
>> library.
> 
> Well, if a..b simply maps to an interval type in the standard library
> (as I think it should) then you can implement the "in" operator in the
> standard library, outside of the language, if you want.

I think a lot of my uneasiness with having intervals in the language is
the syntax.

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.

Also, if you say to someone, "we have intervals, look: [a..b]!" I'd be
surprised if a good proportion of people didn't assume that it was
inclusive both sides.  That's how it'd be interpreted by math people.

Using ... to indicate an inclusive range doesn't solve the problem.  How
do you do (a,b]?  Introduce yet another operator?  What about (a, b)?

The only syntax I've ever liked for ranges is the math syntax.  Sadly,
it's pretty horrible for a programming language, and I don't think it's
even context free.

a..b in slicing and foreach is OK because it's for a very specific,
well-understood purpose.  It's like how range(5) in Python generates the
sequence [0, 1, 2, 3, 4] because 90% of the time, that's what you want
in the circumstances where it's commonly used.

The argument that you can now easily test to see if a number is in a
range is also a little underwhelming.  It's not THAT hard to write the
test out manually.

On the whole, I think the use cases for this sort of syntax are just far
too few and specialised to warrant syntax for them, especially when the
syntax proposed is very restrictive.

Especially when you can do it in a library without too much effort.
Hell, my first instinct was to alias inter to Z to make it even shorter.
 Then it's only 3 characters more than native syntax, and more flexible.

I understand the desire to see something potentially useful in the
language.  I just don't want to see D become like Perl (or to an extent,
C++) where every feature that's even a little useful gets added, and we
end up with a language where everyone has to learn and program in
"subsets" of it, because no normal person could possibly remember how
the whole thing works.

  -- Daniel