www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3543] New: : ? operator can't find common type for interfaces

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3543

           Summary: : ? operator can't find common type for interfaces
           Product: D
           Version: 1.051
          Platform: Other
        OS/Version: All
            Status: NEW
          Keywords: rejects-valid
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: nfxjfg gmail.com



The following fails to compile, but I think it should be allowed:

interface Root {
}

interface A : Root {
}

interface B : Root {
}

bool bla;

void main() {
  A a;
  B b;
  Root r;
  //this works
  r = a;
  r = b;
  //this line fails, although there's an unambiguous common type "Root"
  r = bla ? a : b;
}

If the compiler rejects this intentionally, this bug report is a feature
request.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 23 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3543




This also fails if you're doing this with classes (just replace "interface"
with "class" in the example above).
With classes, this should definitely work, but it fails.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 23 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3543




Note how this makes array literal type inference suck in dmd 2.037:

class Root {
}

class A : Root {
}

class B : Root {
}

bool bla;

void main() {
  A a;
  B b;
  Root t;
  t = a; t = b; //works
  //Error: cannot implicitly convert expression (a) of type fgd.Root to fgd.B
  Root[] t2 = [a, b];
}

If this bug gets fixed, array literal type inference in D2 will be improved.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 26 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3543


nfxjfg gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc



*** Issue 4030 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 28 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3543


Simen Kjaeraas <simen.kjaras gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simen.kjaras gmail.com



PDT ---
*** Issue 5156 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 02 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3543


nfxjfg gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3543


Brad Roberts <braddr puremagic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |braddr puremagic.com
         Resolution|WONTFIX                     |


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3543


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com



21:21:03 PDT ---


 This also fails if you're doing this with classes (just replace "interface"
 with "class" in the example above).
 With classes, this should definitely work, but it fails.


It works with classes when I try it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 05 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3543


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement



21:39:01 PDT ---
I'm going to mark this as an enhancement. When the inheritance graph is
non-trivial, I don't think it's so obvious which, if any, of the ancestors
should be picked. Perhaps the user should decide.

So I'm skeptical this is a good idea.

Meanwhile, it does work for classes, which make sense because classes are
single inheritance. A common root, if there is one, would be only one.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 05 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3543


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei metalanguage.com



22:51:07 PDT ---
Interface hierarchies for a single-rooted DAG. In the DAG there are one or more
common ancestors for any pair of nodes. The most specific one (farthest from
the root) must be chosen. If there are two or more at the same depth that's an
ambiguity error.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 05 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3543




10:51:03 PDT ---


 Interface hierarchies for a single-rooted DAG. In the DAG there are one or more
 common ancestors for any pair of nodes. The most specific one (farthest from
 the root) must be chosen. If there are two or more at the same depth that's an
 ambiguity error.


Interface hierarchies are not necessarily single rooted. They are multiply
inherited.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3543




12:44:13 PDT ---
One can always connect an imaginary root to all rootless interfaces and apply
the rule I mentioned. Let me add that "?:" is a cornerstone operator for a lot
of traits and type deduction paraphernalia (e.g. std.traits.CommonType). I
wouldn't insist in the matter if it weren't important beyond the convenience of
"?:" itself.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3543




13:10:03 PDT ---


 One can always connect an imaginary root to all rootless interfaces and apply
 the rule I mentioned. Let me add that "?:" is a cornerstone operator for a lot
 of traits and type deduction paraphernalia (e.g. std.traits.CommonType). I
 wouldn't insist in the matter if it weren't important beyond the convenience of
 "?:" itself.


I agree about the importance of the ?: algorithm. But I wonder if the compiler
picking a common ancestor from a complex inheritance graph is really a good
thing - it may prove surprising to the user. For example:

interface A : B,C,D,E
interface X : M,N,O,C

Is it really the right idea to pick C for the common type? I'm skeptical.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3543




13:26:45 PDT ---




 One can always connect an imaginary root to all rootless interfaces and apply
 the rule I mentioned. Let me add that "?:" is a cornerstone operator for a lot
 of traits and type deduction paraphernalia (e.g. std.traits.CommonType). I
 wouldn't insist in the matter if it weren't important beyond the convenience of
 "?:" itself.


 
 I agree about the importance of the ?: algorithm. But I wonder if the compiler
 picking a common ancestor from a complex inheritance graph is really a good
 thing - it may prove surprising to the user. For example:
 
 interface A : B,C,D,E
 interface X : M,N,O,C
 
 Is it really the right idea to pick C for the common type? I'm skeptical.


Yes, in this case D is unequivocally the common type. A more interesting
example is:

interface A {}
interface B {}
interface C : B {}
interface X : A, C {}
interface Y : A, C {}

By my suggested rule, C would be the common type as it's the most specific
(most remote from a root). At the same time both A and C are equally distanced
from X and Y so it's legitimate to ask on why A is not an equally good fit (and
therefore an ambiguity).

A rule that would avoid that issue would be to count all common ancestors and
find the one that is closest to both, i.e. shortest sum of steps from both
interfaces. I thought of it but eliminated it because it can create rather
subtle distinctions.

I agree the problem is not as clear cut as we'd like. OP?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 06 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3543




Even modifying :? just for class instances will be a good improvement, this is
not accepted by dmd 2.052:


class A {}
class B : A {}
class C : A {}
void main() {
    B b = new B;
    C c = new C;
    A[] array = [b, c];
}

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