What would be the consequence of implementing interfaces as fat pointers ?

[Michel Fortin]

On 2014-04-01 14:17:33 +0000, Manu <turkeyman at gmail.com> said:

> On 1 April 2014 22:03, Michel Fortin <michel.fortin at michelf.ca> wrote:
> 
>> On 2014-04-01 07:11:51 +0000, Manu <turkeyman at gmail.com> said:
>> 
>>> Of course, I use alias this all the time too for various stuff. I said
>>> before, it's a useful tool and it's great D *can* do this stuff, but I'm
>>> 
>>> talking about this particular super common use case where it's used to
>>> hack
>>> together nothing more than a class without a vtable, ie, a basic ref type.
>>> I'd say that's worth serious consideration as a 1st-class concept?
>>> 
>> 
>> You don't need it as a 1st-class D concept though. Just implement the
>> basics of the C++ object model in D, similar to what I did for Objective-C,
>> and let people define their own extern(C++) classes with no base class.
>> Bonus if it's binary compatible with the equivalent C++ class. Hasn't
>> someone done that already?
> 
> I don't think the right conceptual solution to a general ref-type intended
> for use throughout D code is to mark it extern C++... That makes no sense.

I was thinking of having classes that'd be semantically equivalent to 
those in D but would follow the C++ ABI, hence the extern(C++). It 
doesn't have to support all of C++, just the parts that intersect with 
what you can express in D. For instance, those classes would be 
reference types, just like D classes; if you need value-type behaviour, 
use a struct.

But maybe that doesn't make sense.

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca