[Issue 1023] Struct implementing interfaces and struct member enumeration

d-bugmail at puremagic.com d-bugmail at puremagic.com
Fri Oct 22 01:50:06 PDT 2010


http://d.puremagic.com/issues/show_bug.cgi?id=1023


Austin Hastings <ah08010-d at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ah08010-d at yahoo.com


--- Comment #6 from Austin Hastings <ah08010-d at yahoo.com> 2010-10-22 01:49:18 PDT ---
I'd like to bump this request, and maybe make it a little more specific. What
I'm looking for is essentially a "duck interface" - that is, "this type
supports these methods, carry on." Except that I want strong enforcement - "you
told me that you would support these methods, but you don't. Error."

Adding 'static interface' might be the way to differentiate between
class-interface and struct-interface. This is by analogy with the behavior of
static in a nested-function context (has no 'this', etc.).

In my case, struct is the right mechanism for speed and stack allocation, while
the interface is nice to provide a single point to document and to have the
compiler verify. If I've forgotten one of the eleventy-seven possible
specializations, I want the compiler to tell me.

So for example, if an interface is declared "static interface" or "duck
interface" or whatever, then getting a reference to it is impossible, because
it makes no promises about the underlying type. It could be a class, it could
be a struct, it could be an enum.

However, you could mix in duck interfaces anywhere, and the compiler verify
them. And similarly, you could use them to annotate symbols, but that might
need a little syntactic sugar:

static interface Duck;
class Base;
class Derived : Base, Duck;

struct Mallard : Duck;

auto obj = new Derived(); 
obj.quack();

auto s = Mallard();
s.quack();

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list