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



--- Comment #10 from Steven Schveighoffer <schveiguy@yahoo.com> 2011-07-11 09:08:48 PDT ---
(In reply to comment #9)
> On a semi-related but not all that related note

Interesting :)

> I would point out to Steven
> that Kenji has made pull requests related to std.conv.to, one of which will
> make std.conv.to use opCast for user-defined conversions if a user-defined type
> has an opCast, so if you don't think that opCast should be used for such
> situations (that is, if you equate that to dangerous as you've been discussing
> here), then you should comment on the pull request:

calling opCast!(T) directly is not nearly as dangerous as using cast(T).  It is expected that opCast does not do unsafe things.  Plus it is a regular function, so it must obey the type system (unless of course it uses casts underneath). In particular, it does *not* affect const/immutable unless opCast is specifically written to do so.

So I have no problem with opCast being called from std.conv.to.

Actually, I'm looking at std.conv.to in that pull request and see a significant bug, because cast is so dangerous! (will file in a minute)

-- 
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=2270



--- Comment #11 from Steven Schveighoffer <schveiguy@yahoo.com> 2011-07-11 10:20:10 PDT ---
(In reply to comment #10)
> Actually, I'm looking at std.conv.to in that pull request and see a significant bug, because cast is so dangerous! (will file in a minute)

Note issue 6288

-- 
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=2270



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

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


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #13 from bearophile_hugs@eml.cc 2011-07-11 16:03:56 PDT ---
(In reply to comment #12)

> 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?)

Some casts are easy enough to implement in Phobos library code, as example see bug 5559

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