Shouldn't an attempt to perform an invalid downcast throw an exception? The
current behaviour of having the cast operator return null for those cases forces
a pattern of error checking reminiscent of the C library. Or have the cases
where this could be a problem considered bad programming practices anyway?
The documentation doesn't explain the rationale behind the current behaviour,
and I was under the impression that it was considered good practice to detect
error conditions ASAP (instead of having a null pointer exception thrown later).
Since this is my first post to this newsgroup, let me just compliment you guys
on what is shaping up to be an extremely interesting language. I'm looking
forward to make some contributions myself to this effort.

I believe one of the rationales is so one can do something like:
if (cast(A)b){}
To test if b is of type A.  If an exception was thrown, one would have to
catch the exception and deal with a simple if with a try catch instead.
In addition, exceptions are (from what I've heard) slow, especially
compared to if(null).

John

On Wed, 18 Aug 2004 16:38:56 +0000, edgar wrote:

> Shouldn't an attempt to perform an invalid downcast throw an exception? The
> current behaviour of having the cast operator return null for those cases forces
> a pattern of error checking reminiscent of the C library. Or have the cases
> where this could be a problem considered bad programming practices anyway?
> The documentation doesn't explain the rationale behind the current behaviour,
> and I was under the impression that it was considered good practice to detect
> error conditions ASAP (instead of having a null pointer exception thrown later).
> Since this is my first post to this newsgroup, let me just compliment you guys
> on what is shaping up to be an extremely interesting language. I'm looking
> forward to make some contributions myself to this effort.

edgar wrote:

> Shouldn't an attempt to perform an invalid downcast throw an exception? The
> current behaviour of having the cast operator return null for those cases forces
> a pattern of error checking reminiscent of the C library.
<snip>

I think the idea is that the error is checked indirectly.  Because when you try to use the null object, it'll generate an access violation....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on on the 'group where everyone may benefit.

Current behaviour merges the downcast and a test for a downcastability.

Say, you have a polymorphic container which collects Berries. You take one berry and want to determine what to do with it:
if(cast(Strawberry)berry)
	eat(berry);
else if(cast(BlackCurrant)berry)
	makeJam(berry);
else GiveSomeoneElse(berry);

Of course one could take some other way for testing the downcastability, but then for any of such operations this would have to be done twice.

As opposed to Java, where polymorphic containers were used for everything up to now and downcasting bugs are very likely and should be caught as early as possible, in D downcasting is only needed in special cases which requiere attention anyway. I don't think D's decision would lead to many problems in practice, though definately to some.

A possible alternative would be to make cast safe (that is throw an exception) and provide a downcast with current symantics in a form of something like a member function to classes.

-eye

edgar schrieb:
> Shouldn't an attempt to perform an invalid downcast throw an exception? The
> current behaviour of having the cast operator return null for those cases forces
> a pattern of error checking reminiscent of the C library. Or have the cases
> where this could be a problem considered bad programming practices anyway?
> The documentation doesn't explain the rationale behind the current behaviour,
> and I was under the impression that it was considered good practice to detect
> error conditions ASAP (instead of having a null pointer exception thrown later).
> Since this is my first post to this newsgroup, let me just compliment you guys
> on what is shaping up to be an extremely interesting language. I'm looking
> forward to make some contributions myself to this effort.
> 
>