http://d.puremagic.com/issues/show_bug.cgi?id=2270
--- Comment #12 from Stewart Gordon <s...@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: -------