On Thursday, 30 July 2015 at 10:40:59 UTC, Atila Neves wrote:
You still wouldn't get a better error message here than with:
struct MyRange {
...
static assert(isInputRange!MyRange);
}
It's less typing, but you still wouldn't know why the static
assertion failed. Now, if we make Adam's idiom in my
aforementioned pull request the go-to thing, then this would be
good:
@satisfies!(checkInputRange, MyRange) struct MyRange { ... }
There's still the problem of having two names for each
constraint: checkInputRange and isInputRange. But... we could
also establish the convention of checkXXX and use string mixins
to turn this:
@satifies!(isInputRange, MyRange)
into (which works cos I just tried it):
template satisfies(alias Constraint, R) {
enum check = "check" ~ Constraint.stringof[2..$-3] ~ "!(R)";
enum assert_ = "static assert("~ check ~ ");";
mixin(assert_); //mixes in "static
assert(checkInputRange!R)"
}
@satisfies!(isInputRange, Zeroes)
struct Zeroes {
enum empty = false;
void popFront() {}
@property int front() { return 0; }
}
Now, _this_ I could go for.
Atila
I might be overthinking this.
You would still need to define something for checkInputRange. Are
you thinking something simple like
template checkInputRange(R)
{
enum bool checkInputRange = isInputRange!R;
}
In this case, the error message is still referring to
checkInputRange instead of isInputRange. So the user would still
need to refer to that and see what that functions conditions are.
Alternately, you could write checkInputRange to provide the user
information about which functions are not implemented (like no
pop, no popFront, no empty). That seems more difficult, but would
be convenient for the user.
The benefit of something simple like
template satisfies_alt(alias Constraint, R) {
static assert(Constraint!R);
}
is that at least you don't have to write extra functions. You
only need isInputRange. The downside is that the error message
references Constraint instead of isInputRange. That's less
intuitive.
