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.
