Constraints

[Chris Cain]

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.