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.