Structs in D are very simple which is good, but in some cases they are just too simple. In many cases you would want to handle struct instances as if they were Object derivates, by calling methods on them, methods that implement an interface. The most obvious example is toUtf8 (or toString). As it is now, for instance in a formatter, if it detects that the input is a struct, you have no way of figuring out whether the struct implements an interface or not.

This is thus a request to make it possible to say that a struct implements an interface and thus can be typeid'ed on other types (interfaces) than those of the structs themselves. An enumeration of the methods of the struct would also be nice.

Thanks :)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Lars Ivar Igesund wrote:
> Structs in D are very simple which is good, but in some cases they are just
> too simple. In many cases you would want to handle struct instances as if
> they were Object derivates, by calling methods on them, methods that
> implement an interface. The most obvious example is toUtf8 (or toString).
> As it is now, for instance in a formatter, if it detects that the input is
> a struct, you have no way of figuring out whether the struct implements an
> interface or not.
> 
> This is thus a request to make it possible to say that a struct implements
> an interface and thus can be typeid'ed on other types (interfaces) than
> those of the structs themselves. An enumeration of the methods of the
> struct would also be nice.
> 
> Thanks :)

If there are no serious technical reasons not to do this,
++votes;  // :)


--
Tomasz Stachowiak

Reply to Tom,

> Lars Ivar Igesund wrote:
> 
>> Structs in D are very simple which is good, but in some cases they
>> are just too simple. In many cases you would want to handle struct
>> instances as if they were Object derivates, by calling methods on
>> them, methods that implement an interface. The most obvious example
>> is toUtf8 (or toString). As it is now, for instance in a formatter,
>> if it detects that the input is a struct, you have no way of figuring
>> out whether the struct implements an interface or not.
>> 
>> This is thus a request to make it possible to say that a struct
>> implements an interface and thus can be typeid'ed on other types
>> (interfaces) than those of the structs themselves. An enumeration of
>> the methods of the struct would also be nice.
>> 
>> Thanks :)
>> 
> If there are no serious technical reasons not to do this, ++votes;  //
> :)

The only technical problem with doing this is the way that interfaces are implemented. IIRC when a class implements an interface, a second v-tbl pointer is inserted into the class. The layout of this table is defined by the interface. One of the members (I'll assume the first, but I'm guessing) is the offset between the v-tbl pointer and the beginning of the object. This allows for methods of a class to be called by way of an interfaces something like this:

I i;

// get fn ptr        get this for obj
((*i)[I.method])   ((i + (*i)[0]), /* other args */ );

An alternative implementation that I have floated before would use a pair of pointers, one to the v-tbl and one to the context. A call would look something like this

I i;
(i.vtbl[I.method])(i.context, /* other args */ );

The down side to this is that it makes a interface instance twice as big and would require all code using interfaces to be recompiled, the up side is that it has no effect what so ever on the layout of the thing that
implements the interface. This would allow structs to implement an interface wile still being plain old data. This would also allow for interface 

literals where the context pointer is a function stack frame as with a delegate.

> 
> --
> Tomasz Stachowiak