On Sunday, 15 March 2015 at 10:40:17 UTC, w0rp wrote:
On Sunday, 15 March 2015 at 08:29:01 UTC, bearophile wrote:
Observe:
https://github.com/D-Programming-Language/phobos/pull/3054
Is this change the partial proof of another failure of a part
of D language design? What's the point of template
constraints? Aren't C++ Concepts better? Or to rephrase that
in a less trollish way, can D be enhanced to add user-defined
error messages to template constraints, and is such
enhancement a good idea?
Bye,
bearophile
It's funny you mentioned concepts, because I was just watching
Bjarne's CppCon 2014 keynote again and I took away two things
from it.
1. For the overwhelming majority of things Bjarne wants from
C++ mentioned in that keynote, D has done all of them, and
better...
2. ...except for concepts.
I believe D does the template error message thing a *whole lot*
better than C++. That's all because of template constraints,
static if, and static assert, and I believe those are down to
Andrei's influence. (Though others likely deserve credit for
their design, implementation, and maintenance. As always you'll
probably have to nod to Kenji who works like crazy.)
I've been wondering what we can do to make specifying
constraints for something like ranges a little easier to write,
with obviously some underlying complexities which will be hard
to implement. This doesn't address your concern about error
messages for constraints really, but what I've thought of is
roughly this.
Say you write 'copy' currently. You'll do something like this.
void copy(InputRange, OutputRange)(InputRange inputRange,
OutputRange)
if (isInputRange!InputRange && isOutputRange!OutputRange) {
/* Some implementation of copying. */
}
Maybe you'll use less verbose names and all kinds of things,
but essentially that is what you're after. I've been wondering
if it's possible to use compiler magic to make this possible.
// These names conflict with our interfaces in std.range,
whatever, imagine
// some other name place of them if you like.
template InputRange(T) {
enum InputRange = isInputRange!T;
}
// The newer syntax makes the above easier...
enum OutputRange(T) = isOutputRange!T;
// Now this works with magic...
void copy()(InputRange inputRange, OutputRange outputRange) {
/* Some implementation of copying. */
}
If you write this now, the compiler will print an error saying,
"Hey, you just attempted to use this template which takes one
argument as a type in this paramter list right here." My idea
is to take that information and instead of returning an error,
just go, "Oh, I'll just add another template parameter onto the
end of your template parameter list here, replace the thing
which really should be a type here with T from the parameter
list, use deduction to insert the type for T and then use it,
then use the template you had originally as a test on the type
T yielding our boolean expression." I left the extra parens in
there for 'copy' as I reckon they'll probably be a requirement
anyway, and then you can't make accidental templates.
You might have to read what I wrote four times to make sense of
it, but that's my crazy idea others can destroy. I'm more of a
wild idea guy than a formal specification guy.
I am not sure of what you want to do but that looks like
"meta-type" like :
void copy(InputRange IRage, OutputRange ORange) (IRange src,
Orange dest) {
/* Some implementation of copying. */
}
Hashkell has something like that for a long times (early 90s I
think) wich is call type classes. Essentially, it checks that the
type implement a certain interface (operators included). You
could do the same in c++ with boost (now maybe std)::is_base_of I
think.
