On Saturday, 27 October 2012 at 16:19:43 UTC, H. S. Teoh wrote:
[snip]
I think there is some merit to being able to declare concepts;
for
example:
// This concept matches any type that has fields that satisfy
// what's specified inside the body.
concept InputRange(T) {
bool empty; // this matches @property bool empty() too
T front;
void popFront();
}
auto myRangeBasedFunc(InputRange r) {
r.popBack(); // compile-time error: InputRange does
// not define .popBack
}
This way, *both* the user of the template and the template
writer are
kept "honest" (i.e., they both have to conform to the
requirements of an
input range). The compiler can thus statically check the
template for
correctness *before* it ever gets instantiated.
Not only so, the compiler will be able to generate a meaningful
error
message when the templates fail to match -- it can tell the
user "the
template didn't match 'cos struct X that you tried to pass to
it isn't
an InputRange, nor a ForwardRange, ... etc.".
We've had a short discussion with Jacob Carlborg about almost
exactly this syntax
(http://forum.dlang.org/post/jukabm$1btd$1...@digitalmars.com) in
the context of better compiler messages.
I will quote my concerns:
=====
void foo (InputRange range);
1. How would you signify `foo` is generic ?
For complier it's probably possible - by type of `InputRange`,
but that will be one more special case
What about user ?
2. How would you put 2 constraints on `range` ?
3. Also you forgot to address:
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
(inout int _dummy=0)
{
R r = void; /// how would you express this
/// b.t.w. ?
range.d comment on this line is "can define a range object".
===== end quote
However I do agree it would be nice if compiler verifies template
body against constraints. IMNA compiler-writer, but I wonder if
it's possible with current syntax.
