Ranges

[Yigal Chripun]

dsimcha wrote:
> == Quote from bearophile (bearophileHUGS at lycos.com)'s article
>> Yigal Chripun:
>>> point in case, look how much
>>> unnecessary confusion Ranges cause which would be eliminated had D
>>> allowed for compile-time interfaces.
>> What are interfaces from the point of view of the compiler?
> 
> Abstract classes with only pure virtual functions.  In other words, basically
> under the hood, an interface is just the layout of a vtable.

That's run-time interfaces. compile-time interfaces are like C++ concepts.
> 
> This actually leads to a comment I want to make in the wider debate:  I personally
> find explicit interfaces really, really annoying and I think that duck typing is
> by far the most intuitive type system there is.  I used to program primarily in
> duck typed languages and resort to every kludge imaginable for speed.  What
> attracted me to D was that the templates and type inference are so powerful that I
> almost feel like it's still a duck typed language, but much faster and with more
> error checking.  I guess that's why I like ranges so much.

duck-typing has its benefits, that's for sure. it all boils down to is 
style issues I guess - do you prefer implicit or explicit interfaces.

either are fine by me, even though it seems to me that duck-typing is 
more of a dynamically typed language feature but maybe my feeling here 
is wrong.
either way, the language needs to be consistent about it in order to not 
confuse users unnecessarily.

> 
> Also, while the fact that you need interfaces to specify a vtable layout is an
> implementation detail, I would argue that, in close to the metal languages, it
> does more harm than good to try too hard to prevent implementation details from
> leaking into the language abstractions.  Otherwise, what would be the point of it
> being a close to the metal language?  The fact that, for templates, one does not
> need to specify vtable layouts and for OO you do justifies the asymmetry between
> templates and OO.  Interfaces for templates would just add boilerplate and make
> explicit something that is already implicitly knowable and checked at compile time
> anyhow.

here I disagree. it sometimes makes sense to let implementation details 
leak into your abstractions when you gain something by it, like 
performance (e.g. "Worse is better" principle) but I don't see how this 
applies here. what is there to gain by doing this compromise in this case?
there is no added performance since it's all compile-time, there is no 
additional flexibly like with run-time duck-typing.