Interfaces, traits, concepts, and my idea for a DIP

[jmh530 via Digitalmars-d]

On Tuesday, 28 July 2015 at 13:23:37 UTC, Daniel Kozák wrote:
>
> I would use something like this:
>
> @interface(InputRange, ...)
> struct MyRange { ... }
>
>
> @interface(InputRange, ...)
> class MyClassRange { ... }

I get the change from isInputRange to InputRange, because 
isInputRange is like a templated bool or something and InputRange 
is an interface. But why the suggestion of user-defined 
attributes?

As an aside, I'm still trying to understand the reasoning behind 
some of the decisions around structs and inheritance. The big 
difference between structs and classes is that structs are value 
types and classes are reference types. I'm not entirely sure on 
all the implications of that. My guess is that it helps to know 
how big a value type is in advance (at compilation). So if you're 
inheriting virtual methods in a struct, then you won't 
necessarily know how big it will be and that can be problem. 
However, I would think that final and static methods wouldn't be 
an issue.

Coming around to interfaces, they only allow virtual methods 
without implementation, plus final and static methods. I would 
think the last two would work fine with structs because they 
should be known at compile time, so the only part I'm not sure 
about is the way the virtual methods without implementation would 
work. It seems like to implement what the OP is suggesting you'd 
need some separate rule for handling struct inheritance of 
interfaces so that they are not virtual in the same manner as 
they would be for classes.