static interface

[Andrei Alexandrescu]

Leandro Lucarella wrote:
> Andrei Alexandrescu, el 16 de noviembre a las 12:19 me escribiste:
>> grauzone wrote:
>>> Leandro Lucarella wrote:
>>>> Why not? ;)
>>> The actual question is if Andrei/Walter are interested at all in
>>> this. Because they didn't show any interest so far. D will
>>> probably be doomed to compile time bug-typing I mean duck-typing
>>> forever.
>> There's an embarrassment of riches when it comes to finding stuff to
>> work on for D2. I think we need to resign ourselves to the idea that
>> we need to focus only on one subset of the stream of good ideas that
>> are being proposed.
> 
> I completely agree and understand. I wish I had the time to make patches
> myself for the things I propose. But it's very different if something is
> not implemented because it sucks or just because the lack of men power :)
> 
> If some good feature has Walter's blessing, maybe other person can
> implement it. Nobody wants to implement something if it doesn't have
> Walter's blessing, because we all know he's very tough to convince, and
> nobody wants to work on something it won't get accepted.

What I can tell is that Walter's keenness on adding/changing something 
has a 10-fold improvement if a patch is present. For example Walter was 
sort of ambivalent about opDollar and opDollar!(dim)() until Don simply 
added it.

>> FWIW I was keen on structs interacting in interesting ways with
>> interfaces (and submitted a number of enhancements in that
>> directions) but then realized there are a number of problems that
>> structs/interfaces cannot solve. I believe that a better path to
>> pursue in checking interface conformance is via reflection.
> 
> But that's very laborious, to be honest, I saw some points in std.range
> that would be hard to cover with static interfaces, but for those things
> you have all the flexibility you're already using. But static interfaces
> could cover a wide range of applications, making static duck-typing very
> easy to use.

There's a saying that most all girls may look good in the dark. 
Paraphrasing that, I'd say all language features look nice and easy when 
(a) detail is not discussed, (b) all the rest of the language is assumed 
to be mastered.

There are places in D where we can't do what we want to do. Those are 
top priority. Those that do easier what we can do anyway (struct mixins, 
static interfaces, even the better switch which I actually personally 
like) are below top priority. The barrier is fuzzy because either I, 
Walter, or Don may suddenly catch fancy to a specific thing to work on, 
but I wish we were more, not less disciplined about that.


Andrei