static interface

[Andrei Alexandrescu]

grauzone wrote:
> Andrei Alexandrescu wrote:
>> grauzone wrote:
>>> Andrei Alexandrescu wrote:
>>>> 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.
>>>
>>> That's understandable of course.
>>>
>>>> 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.
>>>
>>> That's a possible solution (and an easy way out to get rid of 
>>> language design problems), but I'm sure it's not the best solution. 
>>> (It also should be a little bit extended to give the user better 
>>> error messages.) I hope cleaner solutions will be considered later, 
>>> possibly after D2 is done.
>>>
>>> Which are the problems you mentioned?
>>
>> I knew this was going to be asked. One issue I remember was that it's 
>> difficult to talk about "a struct must define a type with certain 
>> properties". You will say "but you can express that type as another 
>> interface" but that solves the problem by increasing the size of the 
>> feature. It gets even more complicated when you want to say "defines a 
>> type with these or these other properties, depending on the properties 
>> of this type parameter." I think that all can be solved through 
>> something that is very similar to C++ concepts, and I would want to 
>> avoid going that route.
> 
> In other words, a general solution inside the language would be too 
> complex (because it had to support all sorts of type interfaces), so 
> you'll just leave it to the user, who will implement the same thing with 
> is() and friends?

I don't think that's a fair characterization. With reflection you can 
implement such capability in a library. Sometimes a motivated and 
well-intended feature could grow into a monster of generalization. This 
is what happened to C++ concepts and what could have happened to typedef 
if we hadn't clipped it.

Andrei