Ben Hinkle wrote:
<snip>
> I'm lost. The problem with, for example, returning an interface reference when the base class is declared to return an object reference is that interface references and object references aren't interchangable. They point to different memory locations. So I don't see why you say the lack of interface covariance has nothing to do with the references - it is exactly because of the references.

The post you quoted the link to has only one thing to do with returning interface references, namely that _one_ of the interface functions returns an interface reference.  But the basic issue raised there is that which is still present by removing hjkl from the code sample.

----------
class Yuiop {}

interface Qwert {
    Yuiop zxcvb();
}

class Asdfg : Yuiop, Qwert {
    Asdfg zxcvb() { return null; }
}
----------

Now returning an interface reference doesn't factor into the equation in any way, shape or form.  And the compiler error still shows.  And even in the original post, you still could've noticed that the compiler complains about zxcvb as well.

>>> Is it unfortunate? yes. Is it unreasonable? no. Is it fixable? maybe - I don't know.
>> My answer would be "yes" to all three questions.  And it should be a simple fix.  It just a matter of the compiler determining that an interface method is implemented in the same way as it determines that a class method is overridden.
> 
> I know these things have come up in the past. For example http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/9108. Please state what the "simple fix" is in more detail because I don't see how you can make interfaces covariant with classes.
<snip>

How does the compiler know that a method overrides one in a base class?

It has semantically analysed the base class definition, and generated its vtbl and a symbol table mapping the method names and signatures of the base class to vtbl slots.

When it comes to the derived class, as it fills in the vtbl it checks the base class symbol table to see if any function with the same name and matching signature exists in the base class.  When one matches, either exactly or by covariance, it uses the same vtbl slot as the base class did, so that it really does override.

The way I expect interfaces are implemented is that every class that implements an interface has, as well as its regular vtbl, a vtbl for each interface it implements.  If a class implements one or more interfaces, either directly or by being derived from a class that does, it looks up the signature in the symbol table of each of its interfaces, and fills in the slot in its interface vtbl.  All it needs to do is to count covariant matches when doing this, just as it does when overriding in a class.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:dfa5eu$17le$1@digitaldaemon.com...
> Ben Hinkle wrote:
> <snip>
>> I'm lost. The problem with, for example, returning an interface reference when the base class is declared to return an object reference is that interface references and object references aren't interchangable. They point to different memory locations. So I don't see why you say the lack of interface covariance has nothing to do with the references - it is exactly because of the references.
>
> The post you quoted the link to has only one thing to do with returning interface references, namely that _one_ of the interface functions returns an interface reference.  But the basic issue raised there is that which is still present by removing hjkl from the code sample.
>
> ----------
> class Yuiop {}
>
> interface Qwert {
>     Yuiop zxcvb();
> }
>
> class Asdfg : Yuiop, Qwert {
>     Asdfg zxcvb() { return null; }
> }
> ----------
>
> Now returning an interface reference doesn't factor into the equation in any way, shape or form.  And the compiler error still shows.  And even in the original post, you still could've noticed that the compiler complains about zxcvb as well.

Oh, OK. I was just looking at the hjkl example. I agree there shouldn't be any technical challenge to having the above example work.

>>>> Is it unfortunate? yes. Is it unreasonable? no. Is it fixable? maybe - I don't know.
>>> My answer would be "yes" to all three questions.  And it should be a simple fix.  It just a matter of the compiler determining that an interface method is implemented in the same way as it determines that a class method is overridden.
>>
>> I know these things have come up in the past. For example http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/9108. Please state what the "simple fix" is in more detail because I don't see how you can make interfaces covariant with classes.
> <snip>
>
> How does the compiler know that a method overrides one in a base class?
>
> It has semantically analysed the base class definition, and generated its vtbl and a symbol table mapping the method names and signatures of the base class to vtbl slots.
>
> When it comes to the derived class, as it fills in the vtbl it checks the base class symbol table to see if any function with the same name and matching signature exists in the base class.  When one matches, either exactly or by covariance, it uses the same vtbl slot as the base class did, so that it really does override.
>
> The way I expect interfaces are implemented is that every class that implements an interface has, as well as its regular vtbl, a vtbl for each interface it implements.  If a class implements one or more interfaces, either directly or by being derived from a class that does, it looks up the signature in the symbol table of each of its interfaces, and fills in the slot in its interface vtbl.  All it needs to do is to count covariant matches when doing this, just as it does when overriding in a class.

Gotcha. I agree.

In article <dfa7b4$19c3$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:dfa5eu$17le$1@digitaldaemon.com...
>> Ben Hinkle wrote:
>> <snip>
>>> I'm lost. The problem with, for example, returning an interface reference when the base class is declared to return an object reference is that interface references and object references aren't interchangable. They point to different memory locations. So I don't see why you say the lack of interface covariance has nothing to do with the references - it is exactly because of the references.
>>
>> The post you quoted the link to has only one thing to do with returning interface references, namely that _one_ of the interface functions returns an interface reference.  But the basic issue raised there is that which is still present by removing hjkl from the code sample.
>>
>> ----------
>> class Yuiop {}
>>
>> interface Qwert {
>>     Yuiop zxcvb();
>> }
>>
>> class Asdfg : Yuiop, Qwert {
>>     Asdfg zxcvb() { return null; }
>> }
>> ----------
>>
>> Now returning an interface reference doesn't factor into the equation in any way, shape or form.  And the compiler error still shows.  And even in the original post, you still could've noticed that the compiler complains about zxcvb as well.
>
>Oh, OK. I was just looking at the hjkl example. I agree there shouldn't be any technical challenge to having the above example work.
>
>>>>> Is it unfortunate? yes. Is it unreasonable? no. Is it fixable? maybe - I don't know.
>>>> My answer would be "yes" to all three questions.  And it should be a simple fix.  It just a matter of the compiler determining that an interface method is implemented in the same way as it determines that a class method is overridden.
>>>
>>> I know these things have come up in the past. For example http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/9108. Please state what the "simple fix" is in more detail because I don't see how you can make interfaces covariant with classes.
>> <snip>
>>
>> How does the compiler know that a method overrides one in a base class?
>>
>> It has semantically analysed the base class definition, and generated its vtbl and a symbol table mapping the method names and signatures of the base class to vtbl slots.
>>
>> When it comes to the derived class, as it fills in the vtbl it checks the base class symbol table to see if any function with the same name and matching signature exists in the base class.  When one matches, either exactly or by covariance, it uses the same vtbl slot as the base class did, so that it really does override.
>>
>> The way I expect interfaces are implemented is that every class that implements an interface has, as well as its regular vtbl, a vtbl for each interface it implements.  If a class implements one or more interfaces, either directly or by being derived from a class that does, it looks up the signature in the symbol table of each of its interfaces, and fills in the slot in its interface vtbl.  All it needs to do is to count covariant matches when doing this, just as it does when overriding in a class.
>
>Gotcha. I agree.
>
>

Good then, I didn't wan't to cause any serious fight here :) I can probably live with the restrictions in the D spec. Hopefully this detail gets documented AND also implemented in the compiler (those anonymous segfaults in a high level language really don't sound good.)

Jari-Matti

jmjmak@utu.invalid.fi schrieb:

> interface A {}
> class B:A {}
> 
> void main() {
> A x = new B();
> A y = new B();
> assert(x!=y);	// ok
> printf("1. ok\n");
> 
> B[] u, v;
> u ~= new B();
> v ~= u;
> assert(u==v);	// ok
> printf("2. ok\n");
> 
> A[] a, b;
> a ~= new B();
> b ~= a;
> assert(b==a);	// SEGFAULT!
> printf("3. ok\n");
> }
> 
> //It should be possible to compare interface-type-arrays for equality //since all array elements inherit opEquals from Object.

Added to DStress as http://dstress.kuehne.cn/nocompile/o/opCmp_06_A.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_B.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_C.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_D.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_E.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_F.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_G.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_H.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_I.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_J.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_K.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_L.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_M.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_N.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_O.d

Thomas

Thomas Kühne wrote:
<snip>
> Added to DStress as
> http://dstress.kuehne.cn/nocompile/o/opCmp_06_A.d
> http://dstress.kuehne.cn/nocompile/o/opCmp_06_B.d
> http://dstress.kuehne.cn/nocompile/o/opCmp_06_C.d
> http://dstress.kuehne.cn/nocompile/o/opCmp_06_D.d
> http://dstress.kuehne.cn/nocompile/o/opCmp_06_E.d
> http://dstress.kuehne.cn/nocompile/o/opCmp_06_F.d
> http://dstress.kuehne.cn/nocompile/o/opCmp_06_G.d
> http://dstress.kuehne.cn/nocompile/o/opCmp_06_H.d
> http://dstress.kuehne.cn/nocompile/o/opCmp_06_I.d
> http://dstress.kuehne.cn/nocompile/o/opCmp_06_J.d
> http://dstress.kuehne.cn/nocompile/o/opCmp_06_K.d
> http://dstress.kuehne.cn/nocompile/o/opCmp_06_L.d
> http://dstress.kuehne.cn/nocompile/o/opCmp_06_M.d
> http://dstress.kuehne.cn/nocompile/o/opCmp_06_N.d
> http://dstress.kuehne.cn/nocompile/o/opCmp_06_O.d
<snip>

Why are these all nocompile?  And what is the test function for - just a dummy function to avoid any special handling of empty interfaces?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon schrieb:
> Thomas Kühne wrote:
> <snip>
> 
>> Added to DStress as http://dstress.kuehne.cn/nocompile/o/opCmp_06_A.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_B.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_C.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_D.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_E.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_F.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_G.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_H.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_I.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_J.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_K.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_L.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_M.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_N.d http://dstress.kuehne.cn/nocompile/o/opCmp_06_O.d
> 
> <snip>
> 
> Why are these all nocompile?

Interfaces neither inherite Object's opCmp nor define their own.

>  And what is the test function for - just a
> dummy function to avoid any special handling of empty interfaces?

Yes

Thomas

Thomas Kühne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stewart Gordon schrieb:
<snip>
>> Why are these all nocompile?
> 
> Interfaces neither inherite Object's opCmp nor define their own.
<snip>

Primitive types don't have opEquals or opCmp either.  So if that's the reason, then surely

    int a, b;
    ...
    assert (a == b);
    assert (a < b);

would be equally illegal.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon schrieb:

> Thomas Kühne wrote:
> 
>>
>> Stewart Gordon schrieb:
> 
> <snip>
> 
>>> Why are these all nocompile?
>>
>>
>> Interfaces neither inherite Object's opCmp nor define their own.
> 
> <snip>
> 
> Primitive types don't have opEquals or opCmp either.  So if that's the reason, then surely
> 
>     int a, b;
>     ...
>     assert (a == b);
>     assert (a < b);
> 
> would be equally illegal.

http://www.digitalmars.com/expression.html#RelExpression
Does mention int.., float... and object, but leaves out the interfaces.

Thomas