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



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

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



--- Comment #20 from bearophile_hugs@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: -------

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



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

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



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

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



--- Comment #23 from Sobirari Muhomori <dfj1esp02@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: -------

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



--- Comment #24 from Stewart Gordon <smjg@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: -------

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


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |andrei@metalanguage.com
         AssignedTo|nobody@puremagic.com        |bugzilla@digitalmars.com


--- Comment #25 from Andrei Alexandrescu <andrei@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: -------

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



--- Comment #26 from Jason House <jason.james.house@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: -------

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



--- Comment #27 from Andrei Alexandrescu <andrei@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: -------

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



--- Comment #28 from Andrei Alexandrescu <andrei@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: -------