[Issue 1023] Struct implementing interfaces and struct member enumeration
https://issues.dlang.org/show_bug.cgi?id=1023 Dmitry Olshansky changed: What|Removed |Added Status|NEW |RESOLVED CC||dmitry.o...@gmail.com Resolution|--- |WORKSFORME --- Comment #8 from Dmitry Olshansky --- > An enumeration of the methods of the struct would also be nice. __trait(getMembers, ...) Far as duck typing goes, this may produce a DIP on compile-time interfaces (a-la concepts). And we have had good library solutions that check all of boxes for a long time now, see: https://github.com/atilaneves/concepts Which has `models` UDA to check if struct follows interface statically. --
[Issue 1023] Struct implementing interfaces and struct member enumeration
https://issues.dlang.org/show_bug.cgi?id=1023 Andrei Alexandrescu changed: What|Removed |Added Version|unspecified |D2 --
[Issue 1023] Struct implementing interfaces and struct member enumeration
http://d.puremagic.com/issues/show_bug.cgi?id=1023
Trass3r changed:
What|Removed |Added
CC||mrmoc...@gmx.de
--- Comment #7 from Trass3r 2011-12-13 11:56:26 PST ---
(In reply to comment #6)
> Adding 'static interface' might be the way to differentiate between
> class-interface and struct-interface.
..
> 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.
Exactly!
Phobos circumvents the problem by using lots of templates in constraints:
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
{
R r = void; // can define a range object
if (r.empty) {} // can test for empty
r.popFront(); // can invoke popFront()
auto h = r.front; // can get the front of the range
}));
}
While this works fine, it does have some disadvantages.
It adds lots of overhead cause all of that code must be evaluated with errors
gagged, mustn't alter the AST and whatever. Also there are a lot of bugs
introduced by that here in bugzilla.
Furthermore there are no useful error messages with template constraints, so
you don't even know what exactly went wrong when you implemented the interface.
> 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.
Yep, but one would need them as parameters. Maybe
foo(Bla b)
with Bla being a static interface could be shorthand for a compiler internal
equivalent of the currently used, ugly
foo(Blub)(Blub b) if (conformsToBlaStructure!Blub)
OTOH, how to express if you want a struct conforming to multiple structural
interfaces?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1023] Struct implementing interfaces and struct member enumeration
http://d.puremagic.com/issues/show_bug.cgi?id=1023 Austin Hastings changed: What|Removed |Added CC||ah0801...@yahoo.com --- Comment #6 from Austin Hastings 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: ---
