[Issue 2270] cast produces invalid arrays at runtime

[d-bugmail at puremagic.com]

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


Steven Schveighoffer <schveiguy at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|wrong-code                  |
                 CC|                            |schveiguy at yahoo.com
           Severity|normal                      |enhancement


--- Comment #8 from Steven Schveighoffer <schveiguy at yahoo.com> 2011-07-11 08:05:14 PDT ---
Casting is for all intents and purposes a blunt instrument.  The fact that cast
can call runtime functions or member functions in certain situations somewhat
muddies the waters.

IMO, cast should be reserved for specifically "I know what I'm doing" stuff. 
dynamic cast (casting from a base to derived class) should really be handled by
a library function, as it is so dangerous to use cast in this case (you can
unintentionally remove const or immutable).  Same thing for opCast.

For me, the litmus test for this is:

float f = 1.5;
int i = cast(int)f; // now contains 1

float[] farr = [1.5, 2.5];
int[] iarr = cast(int[])farr;

is it reasonable for someone to expect iarr to contain the binary float
representation of [1.5, 2.5], or should it contain [1, 2]?

I think both cases are reasonable, and the former is much more difficult to do
a different way, whereas a library function already exists to do the latter
(std.conv.to).  It would be extremely inconsistent for arrays to cast
differently depending on the element type.  Remember that arrays are akin to
pointers, and should cast similarly (casting a pointer does nothing except
reinterpret the type).

The final thing is, cast should *not* be doing hidden allocations.  I think
this bug is really an enhancement request, because the current code works as
designed.  Marking as such.

(In reply to comment #6)
> (In reply to comment #5)
> > I do understand, but nothing you've said changes the fact that the behavior is
> > completely intentional. 
> 
> What is your source for this "fact"?

http://www.digitalmars.com/d/2.0/expression.html#CastExpression

Note the lack of special case (and there are several) for casting arrays.  In
fact, mention of array casting should be made there, to indicate how the length
member is affected.  I'd throw in pointer casting as well.

So I'd interpret that as the D spec and the compiler was intentionally *not*
designed to special case casting of arrays of classes to arrays of interfaces
and vice versa.

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