Rant after trying Rust a bit

[Jonathan M Davis via Digitalmars-d]

On Saturday, 25 July 2015 at 03:11:59 UTC, Walter Bright wrote:
> On 7/24/2015 7:28 PM, Jonathan M Davis wrote:
>> I confess that I've always thought that QueryInterface was a 
>> _horrible_ idea,
>
> Specifying every interface that a type must support at the top 
> of the hierarchy is worse. Once again, Exception Specifications.

Well, in most code, I would think that you should be getting the 
actual object with its full type and converting that to an 
interface to use for whatever you're using rather than trying to 
convert something that's one interface into another. It usually 
doesn't even make sense to attempt it. So, the only place that 
has all of the functions is the actual class which _has_ to have 
every function that it implements. I certainly wouldn't argue for 
trying to combine the interfaces themselves in most cases, since 
they're usually distinct, and combining them wouldn't make sense. 
But similarly, it doesn't usually make sense to convert on 
interface to a totally distinct one and have any expectation that 
that conversion is going to work, because they're distinct.

Most code I've dealt with that is at all clean doesn't cast from 
a base type to a derived type except in rare circumstances, and 
converting across the interface hierarchy never happens.

I've never seen QueryInterface used in a way that I wouldn't have 
considered messy or simply an annoyance that you have to deal 
with because you're dealing with COM and can't use pure C++ and 
just implicitly cast from the derived type to the 
interface/abstract type that a particular section of code is 
using.

But maybe I'm just not looking at the problem the right way. I 
don't know.

> I suspect that 3 or 4 years after concepts and traits go into 
> wide use, there's going to be a quiet backlash against them. 
> Where, once again, they'll be implementing D's semantics. Heck, 
> C++17 could just as well be renamed C++D :-) given all the D 
> senabtucs they're quietly adopting.

Well, even if concepts _were_ where it was at, at least D 
basically lets you implement them or do something far more lax or 
ad hoc, because template constraints and static if give you a 
_lot_ flexibility. We're not tied down in how we go about writing 
template constraints or even in using the function level to 
separate out functionality, because we can do that internally 
with static if where appropriate. So, essentially, we're in a 
great place regardless.

On the other hand, if we had built template constraints around 
concepts or interfaces or anything like that, then our hands 
would be tied. By making them accept any boolean expression 
that's known at compile time, we have maximum flexibility. What 
we do with them then becomes a matter of best practices.

The downside is that it's sometimes hard to decipher why a 
template constraint is failing, and the compiler is less able to 
help us with stuff like that, since it's not rigid like it would 
be with a concept supported directly by the language, but the 
sheer simplicity and flexibility of it makes it a major win 
anyway IMHO.

- Jonathan M Davis