On 2011-11-27 02:03, Andrei Alexandrescu wrote:
On 11/26/11 6:40 PM, Kapps wrote:
One of the great things about D is the ability to do so much work at
compile-time, including static verification. An example is the amount of
constraints available for templates, static ifs, etc. But at some point,
it starts getting very problematic to just figure out what something
does, and what something can do. An example for this, is ranges. They
can be very confusing, and you don't know what they can do without
actually going and looking up the exact definition of them. Even then,
you have to know that the templated type a function expects is a range.
Again, very confusing, and arguably messy. Finally, even now that you
know what methods you can call on this mysterious type T, and you see
that there's a clause isInputRange!(T) on the method, your IDE still has
no clue about any of these things making it impossible to have
semi-decent code completion for that type.
Which brings in, compile-time interfaces. It seems like a natural thing
to include when you have the above tools. Instead of having a method
such as:
auto DoSomething(T)(T Data) if(isInputRange!(T)) { }
You could simply do:
auto DoSomething(Range Data) { }
where Range is defined as:
enum interface Range {
void popFront() const;
@property bool empty() const;
@property auto front();
}
What's "auto" here? This thing alone pretty much destroys the idea;
we've considered it very seriously.
Andrei
"auto" cannot be used here. Just like it can't be used in any place
where there is no implementation of a function.
Seems to me it needs to look something like this:
enum interface Range (T)
{
void popFront();
@property bool empty() const;
@property T front();
}
--
/Jacob Carlborg
