There is nothing called a free lunch is this world. If things needed to be resolved then initiative needs a support to be sorted out.

<a href=http://mls.fastrealestate.net>mls</a>

http://d.puremagic.com/issues/show_bug.cgi?id=2095


Steven Schveighoffer <schveiguy@yahoo.com> changed:

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


--- Comment #10 from Steven Schveighoffer <schveiguy@yahoo.com> 2010-03-16 14:23:01 PDT ---
*** Issue 3977 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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2095


bearophile_hugs@eml.cc changed:

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


--- Comment #11 from bearophile_hugs@eml.cc 2010-09-28 18:36:09 PDT ---
I think in this case runtime tests in nonrelease builds are better than nothing.

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

http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #12 from Stewart Gordon <smjg@iname.com> 2010-09-29 02:47:57 PDT ---
(In reply to comment #11)
> I think in this case runtime tests in nonrelease builds are better than nothing.

In what case?  And what would these runtime tests do?

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

http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #13 from bearophile_hugs@eml.cc 2010-11-16 17:04:34 PST ---
Something about this topic:

http://blogs.msdn.com/b/ericlippert/archive/2007/10/17/covariance-and-contravariance-in-c-part-two-array-covariance.aspx

This is is an important problem, that needs to receive more votes and more attention.

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

http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #14 from Sobirari Muhomori <dfj1esp02@sneakemail.com> 2010-11-16 21:55:25 PST ---
(In reply to comment #11)
> I think in this case runtime tests in nonrelease builds are better than nothing.

I'm afraid, there's nothing to test at runtime, and I thought the solution was already chosen to disallow mutable covariance at compile time. I remember there was an attempt to implement the solution, but Steven says the code still compiles.

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

http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #15 from Bruno Medeiros <bdom.pub+deebugz@gmail.com> 2010-11-17 12:24:40 PST ---
For the record, the same problem also occurs with pointer types:

    B* ba=[new B()].ptr;
    A* aa=ba;
    *aa=new A;
    (*ba).methodB(); // (*ba) is expected to be B, but is A

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

http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #16 from bearophile_hugs@eml.cc 2010-11-17 15:13:10 PST ---
(In reply to comment #14)

> I'm afraid, there's nothing to test at runtime,

Some runtime data info may be added, then. There is already some of it for classes and modules.


> and I thought the solution was
> already chosen to disallow mutable covariance at compile time.

I didn't know this.

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

http://d.puremagic.com/issues/show_bug.cgi?id=2095


Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com


--- Comment #17 from Jonathan M Davis <jmdavisProg@gmx.com> 2010-11-17 15:27:51 PST ---
It really should be stopped at compile time. There's not really a good reason to allow it. As much as it first looks like mixing A[] and B[] when B : A should work, it's a _really_ bad idea. Just because a container holds a type which is the base type of another type does not mean that a container which holds the derived type should be assignable/castable/convertable to one which holds the base type.

Really, the only question is whether you can get away with it with some form of const, and I believe that the consensus on it in the newsgroup last time that this was discussed was that you couldn't. I'd have to go digging through the archives though to find the exact thread.

This can and should be disallowed at compile time. It's a definite bug. It just hasn't been fixed yet.

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

http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #18 from Stewart Gordon <smjg@iname.com> 2010-11-17 16:57:33 PST ---
(In reply to comment #17)
> Really, the only question is whether you can get away with it with some form of const, and I believe that the consensus on it in the newsgroup last time that this was discussed was that you couldn't. I'd have to go digging through the archives though to find the exact thread.

I've no idea what discussion you're thinking of either.  But I've studied it - see comment 4.  But to summarise, the following implicit conversions should be allowed:

B[] to const(A)[]
const(B)[] to const(A)[]
immutable(B)[] to immutable(A)[]
immutable(B)[] to const(A)[]

> This can and should be disallowed at compile time.  It's a definite bug.  It just hasn't been fixed yet.

Yes, in the spec.

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