I do kind of like your way better, as it's more succinct and
clear. As of right now I rarely use classes in D because they
just aren't necessary in most cases, and using structs with
templates is nearly as powerful and (probably) generates faster
code (although, probably fatter code as well as it has to make
several versions of the same functions depending on the types).
With your idea, it seems like I would have even less need for
classes because you can specify "interfaces" to that generic code.
That all said, I think your code is tiny bit unrealistic in terms
of usage for these things which make them look far more useful
than they really would be. Take, for instance, some actual code:
https://gist.github.com/2d32de50d2e856c00e9d#file_insert_back.d
So, in this case, I see no potential savings at all. I'd still
have to have "isImplicitlyConvertible" in there and therefore I'd
still need the current constraint on the method. My insertFront
method is more complicated:
https://gist.github.com/2d32de50d2e856c00e9d#file_insert_front.d
But even though it's more complicated, I'd also like to see how
your method would simplify this as well.
Overall, I think it sounds nice in theory, but I'm just not sure
how effective it will be in practice.
I hope I'm not asking too much of you... I'm not trying to
discourage you, I'm asking genuine questions about how this will
work on more realistic code.
On Thursday, 10 May 2012 at 09:43:00 UTC, İbrahim Gökhan
YANIKLAR wrote:
concept CInputRange(R)
{
static assert (isDefinable!R);
static assert (isRange!R);
bool empty();
void popFront();
ElementType!R front();
}
Also, something that would _have_ to be solved is ElementType!R
... as of right now, ElementType!R figures out what a range holds
by what its front() property returns. So, I think this definition
would be invalid.
However, once we can show that this will improve things on real
code and these things are sorted out, I wouldn't mind seeing this
in the language.
