[Issue 2095] covariance w/o typechecks = bugs

2017-02-05 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=2095

anonymous4  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17148

--


[Issue 2095] covariance w/o typechecks = bugs

2015-06-08 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=2095

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

Version|2.012   |D2

--


[Issue 2095] covariance w/o typechecks = bugs

2011-11-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


--- Comment #32 from Walter Bright bugzi...@digitalmars.com 2011-11-24 
10:14:30 PST ---
https://github.com/D-Programming-Language/dmd/commit/7adef956a0ca6352034b34e65f76798af51d6aab

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


[Issue 2095] covariance w/o typechecks = bugs

2011-11-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #33 from Andrei Alexandrescu and...@metalanguage.com 2011-11-24 
10:25:14 PST ---
Terrific!

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


[Issue 2095] covariance w/o typechecks = bugs

2011-06-11 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095


yebblies yebbl...@gmail.com changed:

   What|Removed |Added

   Keywords||patch
 CC||yebbl...@gmail.com


--- Comment #31 from yebblies yebbl...@gmail.com 2011-06-11 09:57:42 PDT ---
https://github.com/D-Programming-Language/dmd/pull/110

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


[Issue 2095] covariance w/o typechecks = bugs

2010-11-27 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095


Andrei Alexandrescu and...@metalanguage.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||and...@metalanguage.com
 AssignedTo|nob...@puremagic.com|bugzi...@digitalmars.com


--- Comment #25 from Andrei Alexandrescu and...@metalanguage.com 2010-11-27 
05:58:02 PST ---
Elevating importance of this as it's a big hole in the type system. Please vote
up.

Solution: Derived[] can be implicitly converted to const(Base)[] in all
situation where pointer adjustment is not needed for converting Derived to
Base. Conversion from Derived[] to Base[] must be rejected statically.

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


[Issue 2095] covariance w/o typechecks = bugs

2010-11-27 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #26 from Jason House jason.james.ho...@gmail.com 2010-11-27 
06:24:58 PST ---
If derived[] is implicitly converted to const(base)[], what happens when I
append another bade object to the array? Should it implicitly convert to
const(base[])?

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


[Issue 2095] covariance w/o typechecks = bugs

2010-11-27 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #27 from Andrei Alexandrescu and...@metalanguage.com 2010-11-27 
06:32:03 PST ---
(In reply to comment #26)
 If derived[] is implicitly converted to const(base)[], what happens when I
 append another bade object to the array? Should it implicitly convert to
 const(base[])?

You can't append a bad object to a const array.

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


[Issue 2095] covariance w/o typechecks = bugs

2010-11-27 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #28 from Andrei Alexandrescu and...@metalanguage.com 2010-11-27 
10:10:58 PST ---
(In reply to comment #27)
 (In reply to comment #26)
  If derived[] is implicitly converted to const(base)[], what happens when I
  append another bade object to the array? Should it implicitly convert to
  const(base[])?
 
 You can't append a bad object to a const array.

Ah, you mean base not bad. Sorry! Conversion Derived[] - const(Base)[] is
fine because the resulting array is not an lvalue.

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


[Issue 2095] covariance w/o typechecks = bugs

2010-11-27 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #29 from Jason House jason.james.ho...@gmail.com 2010-11-27 
12:08:04 PST ---
Doesn't the following make x an lvalue?

const(base)[] x = derived_array;

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


[Issue 2095] covariance w/o typechecks = bugs

2010-11-27 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #30 from Stewart Gordon s...@iname.com 2010-11-27 12:20:15 PST ---
(In reply to comment #29)
 Doesn't the following make x an lvalue?
 
 const(base)[] x = derived_array;

It does ... but appending to x won't alter derived_array.  There was, however,
previously a hole here that was issue 2093.

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


[Issue 2095] covariance w/o typechecks = bugs

2010-11-21 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #24 from Stewart Gordon s...@iname.com 2010-11-21 17:26:38 PST ---
(In reply to comment #23)
? extends A[]
 
 Interesting. This type implies array is mutable, so you can put objects into
 it.

No, because you don't know which subclass of A the particular array is of. 
Java does exactly this with its generics - prevents you at compile-time from
putting objects into the data structure for this reason.  All Java generics do
is compile-time type checking - at run-time, a List is a List.  But arrays are
different.

But each element of the array is mutable.

 Java will check at runtime for array type, but in D arrays don't have rtti.

Yes, because Java arrays don't use generics.  Probably for backward
compatibility, since they were invented long before generics were.  They're
just convertible to arrays of any class higher up the hierarchy.  This has been
claimed as one of the main weaknesses of Java's design.

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


[Issue 2095] covariance w/o typechecks = bugs

2010-11-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #23 from Sobirari Muhomori dfj1es...@sneakemail.com 2010-11-20 
14:30:34 PST ---
   ? extends A[]

Interesting. This type implies array is mutable, so you can put objects into
it. Java will check at runtime for array type, but in D arrays don't have rtti.

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


[Issue 2095] covariance w/o typechecks = bugs

2010-11-19 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #21 from Bruno Medeiros bdom.pub+deeb...@gmail.com 2010-11-19 
15:29:24 PST ---
(In reply to comment #20)
 (In reply to comment #19)
 
  Classes are not like arrays and pointers. These are
  supposed to be lightweight data types, it's out of place for D to have that
  extra runtime data in these lightweight data types (arrays and pointers). It
  worries me that you suggested this change without even considering an 
  approach
  based on fixing/improving the (static) type system.
 
 A solution based on the type system (plus a bit of syntax) as in C#/Java seems
 better. But it's probably better to implement it after the current group of
 features is implemented.

Yes, like I mentioned, Steven's solution has some limitations. For example, if
you have B[] the best you have is being allowed to cast it to const(A)[]. But
that means you wont be able to call mutable methods on the elements of that
array, whereas with a wildcard type such as:
  ? extends A[]
you would be able to call mutable methods of A. So this solution is not
perfect, but it works with existing concepts in D (it only needs const),
whereas we are far away from the point where can add such disrupting and
complex features such as wildcard type. (D's type system seems to be struggling
already as it is)

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


[Issue 2095] covariance w/o typechecks = bugs

2010-11-19 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #22 from Bruno Medeiros bdom.pub+deeb...@gmail.com 2010-11-19 
15:31:03 PST ---
 Yes, like I mentioned, Steven's solution has some limitations. 

I meant Stewart (Gordon), not Steven.

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


[Issue 2095] covariance w/o typechecks = bugs

2010-11-18 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #19 from Bruno Medeiros bdom.pub+deeb...@gmail.com 2010-11-18 
11:10:49 PST ---
I've looked at Stewart Gordon's proposal, and I agree that they are safe and
sound (although it may need to be more detailed or cleaned-up a bit). I
actually had prepared a post over a month ago detailing what is basically the
same proposal and underlying conclusions as Stewart's proposal. I did it when I
came across the code sample in bug #2544, but before I read Stewart's proposal
(which I read only recently). I didn't actually post the text I prepared yet,
since I was waiting to clear up my backlog of D newsgroups message. :S
In any case, the conclusions are the same, especially to the point of realizing
the connection to Java's wildcard generics (which, BTW, are the only way to
express this use case safely, but without further loss of type system
functionality).

As a simple solution, I recommend we adopt Stewart's proposal, which is good
enough I think.
The very best solution would be to have a concept like Java's wildcard's, but
that is too complex in implementation to consider any time soon.

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

Are you out of your mind? Classes are not like arrays and pointers. These are
supposed to be lightweight data types, it's out of place for D to have that
extra runtime data in these lightweight data types (arrays and pointers). It
worries me that you suggested this change without even considering an approach
based on fixing/improving the (static) type system.

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


[Issue 2095] covariance w/o typechecks = bugs

2010-11-18 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #20 from bearophile_h...@eml.cc 2010-11-18 12:38:47 PST ---
(In reply to comment #19)

 Classes are not like arrays and pointers. These are
 supposed to be lightweight data types, it's out of place for D to have that
 extra runtime data in these lightweight data types (arrays and pointers). It
 worries me that you suggested this change without even considering an approach
 based on fixing/improving the (static) type system.

A solution based on the type system (plus a bit of syntax) as in C#/Java seems
better. But it's probably better to implement it after the current group of
features is implemented.

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


[Issue 2095] covariance w/o typechecks = bugs

2010-11-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #15 from Bruno Medeiros bdom.pub+deeb...@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: ---


[Issue 2095] covariance w/o typechecks = bugs

2010-11-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #16 from bearophile_h...@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: ---


[Issue 2095] covariance w/o typechecks = bugs

2010-11-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095


Jonathan M Davis jmdavisp...@gmx.com changed:

   What|Removed |Added

 CC||jmdavisp...@gmx.com


--- Comment #17 from Jonathan M Davis jmdavisp...@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: ---


[Issue 2095] covariance w/o typechecks = bugs

2010-11-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #18 from Stewart Gordon s...@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: ---


[Issue 2095] covariance w/o typechecks = bugs

2010-11-16 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #13 from bearophile_h...@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: ---


[Issue 2095] covariance w/o typechecks = bugs

2010-11-16 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #14 from Sobirari Muhomori dfj1es...@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: ---


[Issue 2095] covariance w/o typechecks = bugs

2010-09-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095



--- Comment #12 from Stewart Gordon s...@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: ---


[Issue 2095] covariance w/o typechecks = bugs

2010-09-28 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095


bearophile_h...@eml.cc changed:

   What|Removed |Added

 CC||bearophile_h...@eml.cc


--- Comment #11 from bearophile_h...@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: ---


[Issue 2095] covariance w/o typechecks = bugs

2010-03-16 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095


Steven Schveighoffer schvei...@yahoo.com changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com


--- Comment #10 from Steven Schveighoffer schvei...@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: ---


Re: [Issue 2095] covariance w/o typechecks = bugs

2009-05-27 Thread bradpiit
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.netmls/a


[Issue 2095] covariance w/o typechecks = bugs

2009-02-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095





--- Comment #9 from ma...@pochta.ru  2009-02-24 03:24 ---
This turned out to be well-known. Bug 926.
In NG: http://www.digitalmars.com/d/archives/17039.html


-- 



[Issue 2095] covariance w/o typechecks = bugs

2009-02-19 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095





--- Comment #7 from ma...@pochta.ru  2009-02-19 03:01 ---
isn't this bug 2093?


-- 



[Issue 2095] covariance w/o typechecks = bugs

2009-02-19 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095





--- Comment #8 from ma...@pochta.ru  2009-02-19 03:09 ---
int[] x=[1,2];
x.length=1;
int[] y=x;
x~=3; // x=[1,3]
y~=4; // x=[1,4]
bug 2093 has little to do with covariance. Added as dependency.


-- 



[Issue 2095] covariance w/o typechecks = bugs

2009-02-18 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095


ma...@pochta.ru changed:

   What|Removed |Added

 CC||la...@virginia.edu




--- Comment #2 from ma...@pochta.ru  2009-02-18 04:40 ---
*** Bug 2544 has been marked as a duplicate of this bug. ***


-- 



[Issue 2095] covariance w/o typechecks = bugs

2009-02-18 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095


ma...@pochta.ru changed:

   What|Removed |Added

OtherBugsDependingO||2573
  nThis||




--- Comment #3 from ma...@pochta.ru  2009-02-18 04:43 ---
solution was proposed in bug 2412 comment 3


-- 



[Issue 2095] covariance w/o typechecks = bugs

2009-02-18 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095


s...@iname.com changed:

   What|Removed |Added

 CC||s...@iname.com




--- Comment #4 from s...@iname.com  2009-02-18 04:53 ---
This and bug 2412 are about covariance of classes.  Bug 2544 describes
covariance of array constancy, which is basically the same but we need to
remember that the solution needs applying to both.

See also
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=81566


-- 



[Issue 2095] covariance w/o typechecks = bugs

2009-02-18 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2095


jason.james.ho...@gmail.com changed:

   What|Removed |Added

 CC||jason.james.ho...@gmail.com




--- Comment #6 from jason.james.ho...@gmail.com  2009-02-18 22:06 ---
I don't know if it's wise to mark bug 2544 as a duplicate of this bug.  For
example, the proposed solution (comment 3) shows a lack of understanding of
this related issue.

Specifically, I believe the proposed solution in bug 2412 comment 3 says the
following would be ok:
class base{}
class derived:base{}

derived[] x = new derived[2];
const(base)[] safe = x;

That really isn't true.  Take the following code that should resize the arrays
in place:
derived[] x = new derived[2];
derived.length = 1;
const(base)[] safe = x;
x ~= new derived(); // x[1] is now valid derived instance
safe ~= new base(); // just overwrote x[1] with a non-derived instance


--