Jarrett Billingsley, el  2 de mayo a las 16:40 me escribiste:
> For that matter, some languages (like C#) have both kinds of casts - one that throws an exception and one that doesn't.  Either can really be implemented in the other, but the null-returning kind is more basic and efficient.

C++ have the 2 too. If you cast a pointer, it returns NULL if the cast fails but if you cast a reference, the cast throws a bad_cast exception if it fails.

Unfortunatelly this can't be done in D (at least in an elegant way) because it's reference semantics for objects. But I thinks std.contracts.enforce[1] is a perfect solution for this:

auto y = enforce(cast(D)x);
// y is not null from here on

Or just use assert if you want the check to be gone in release builds:
auto y = cast(D)x;
assert(y !is null);

[1] http://www.digitalmars.com/d/2.0/phobos/std_contracts.html

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
The number of wars fought between countries
That both have at least one McDonalds is zero

BCS Wrote:

> In most cases forgetting to check the cast return will result in an seg-v from a dereferenced null because you almost always use it as the

In most cases... almost always... When an invalid cast occurs, the error is not in null pointer it's in invalid cast, and replacing InvalidCastException with a hope for NullPointerException is a wrong way.

> Having the "bad cast" -> null is very handy when you don't known if the cast will be good. It mean you can test it without invoking the exception system and all the overhead that entails.

maybe in this case we need some syntax sugar, not a silent cast?

terranium wrote:
> BCS Wrote:
> 
> 
>>In most cases forgetting to check the cast return will result in an seg-v from a dereferenced null because you almost always use it as the 
> 
> 
> In most cases... almost always... When an invalid cast occurs,

it is not an error.

Thinking about it, I can't recall ever casting to a derived type where a failed cast was an indication of a bug. In the few times I have done it, it has always been in the context of "if a is'a B then" (and not just in the code but in the proper function of the program as well).


>>Having the "bad cast" -> null is very handy when you don't known if the cast will be good. It mean you can test it without invoking the exception system and all the overhead that entails.
> 
> 
> maybe in this case we need some syntax sugar, not a silent cast?

a little sugar for the other way might be even handier

// not tested
template Force_Cast(T)
{
	T Force_Cast(U)(U u)
	{
		static assert(is(U : T), "cant cast from " ~
			U.stringof ~ " to " ~ T.stringof);

		if(auto t = cast(T)u)
			return t;
		else
			throw new
			InvalidCastException("failed cast from " ~
			U.stringof ~ " to " ~ T.stringof);
	}
}