[Issue 2270] cast produces invalid arrays at runtime

[d-bugmail at puremagic.com]

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



--- Comment #12 from Stewart Gordon <smjg at iname.com> 2011-07-11 14:41:54 PDT ---
(In reply to comment #8)
> 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.

Indeed, it's a shame D has only one cast operator, which applies to both safe
and unsafe conversions.  Contrast C++, which has five (does dynamic_cast count
as safe?)

> 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,

    int[] iarr = cast(int[]) cast(void[]) farr;

doesn't seem much more difficult to me.  Casting to void[] makes it explicit
that you want to discard the existing semantics of the byte sequence.

> 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.

Indeed, ISTM probably just an oversight that (DM)D silently accepts this cast
that never does anything useful.

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