Ranges

[dsimcha]

== Quote from Tim Matthews (tim.matthews7 at gmail.com)'s article
> dsimcha wrote:
> > == Quote from Yigal Chripun (yigal100 at gmail.com)'s article
> >> Steve Teale wrote:
> >>> Robert Fraser Wrote:
> >>>
> >>>> Steve Teale wrote:
> >>>>> template isInputRange(R)
> >>>>> {
> >>>>>     enum bool isInputRange = is(typeof(
> >>>>>     {
> >>>>>         R r;             // can define a range object
> >>>>>         if (r.empty) {}  // can test for empty
> >>>>>         r.popFront;          // can invoke next
> >>>>>         auto h = r.front; // can get the front of the range
> >>>>>     }()));
> >>>>> }
> >>>>>
> >>>>> I can not possibly be the only D enthusiast who finds this completely
> > incomprehensible.
> >>>> Yeah, that one is a bit tricky, and what makes it worse is that it seems
> >>>> officially sanctioned by Walter/Andrei as the "right way" to check if a
> >>>> type supports some operations. Basically, if you have:
> >>>>
> >>>> is(typeof({ @@@ }()));
> >>>>
> >>>> this means "if I made a function containing @@@, would that function
> >>>> compile?". It's a hack which stems from the way the is expression works.
> >>>>
> >>>>> What is a range?
> >>>> As others have mentioned, it's just a struct (or other type) that
> >>>> happens to support certain operations.
> >>> So does this mean that interfaces are just a tragic mistake. I'd always
> > thought that what you said was a pretty good description of what an interface is!
> >> IMHO, duck-typing in D is a tragic mistake...  This should have been
> >> implemented with compile time interfaces.
> >
> > Why?  Duck typing is incredibly flexible and simple, but the downside is that, in
> > its traditional implementation it's inefficient and only checkable at runtime.
> > The whole beauty of D's template system is that it allows something similar to
> > duck typing that is checked at compile time and has usually negligible (I won't
> > say zero since object file bloat can be practically significant in a few corner
> > cases) overhead.
> It sometimes makes up for a lack of an actual type system but it is not
> a true duck type system built into the language anyway as you have to go
> through the manual process of asking whether it is of a certain type
> through templates.

No you don't, constraints are just to improve overloading capabilities and provide
better error handling if you use a template wrong.