Ranges

dsimcha dsimcha at yahoo.com
Fri Jun 19 19:27:46 PDT 2009


== 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.



More information about the Digitalmars-d mailing list