Reply to terranium,


> I thought it's a known use case (in C# it's used widely and handles
> value types too).
> 

I've never seen it done in D.

terranium Wrote:

> Dee Girl Wrote:
> 
> > But cast that throws is not good primitive. Because you need expensive operation to implement cast that returns null on failure.
> 
> There is only minor need for this silent cast, I believe, so 1) since this is rarely needed, performance penalty is acceptable, 2) if you don't want performance penalty, avoid need for silent cast.

In my code I use often capability test. So cast that returns null is good for me. If I want to make sure I check on my side. In those cases I assign it to a variable that lives longer. So there are few casts that should throw in my code. If you want to make general statement about frequency of cast at best you collect data from programs.

> > If you use cast that throws in D then you are forced in that pattern.
> 
> The unwanted one (and forced to) should be unsafe functionality, rather than safe. The type switch from your example can be implemented in a more efficient way with a type hashtable.

This is incomplete answer. In my compiler implementation for switch if-else test is fast for 4 elements or less. Then linear search is fast up to 32 elements. Only then hash is best. But many variables influence this. Dee Girl

terranium wrote:
> BCS Wrote:
> 
>> you will need to demonstrate a better way. So far no one has.
> 
> Your argument is big need for if(auto y=cast(Y)x) ?
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=71729

I agree with BCS.  There's nothing wrong with the null-returning dynamic cast.  It's exactly what dynamic_cast does in C++.

Dynamic casts are particularly useful when working with interfaces in D, I think.  You've got a big pool of objects and you get one and want to ask "Hey, object, do you implement the IHasCheezburger interface?" so you just cast to IHasCheezburger and do something if it does, something else if it doesn't.  There is nothing "exceptional" happening there, so it doesn't make sense to throw an exception.

I don't really understand what you were getting at with your hashtable example in your other post.  But it sounds like you're saying we should re-implement a subset of the down-casting functionality that is already present in D objects instead of using the built-in dynamic cast capability.  Why should we do that if D already manages it for us?

--bb

BCS Wrote:

> Where would the table be set up?
wherever you want, static constructor is a good choise, maybe static initializer will work too.

> for delegates to work
yes, delegates sould be static functions or member calls

Reply to terranium,

> BCS Wrote:
> 
>> for delegates to work
>> 
> yes, delegates sould be static functions or member calls
> 

delegates can't be static functions (function pointers can) and member calls wouldn't give me access to local variables.

even if all that is addressed, the best implementation of your proposal is a lot more hackish than 

if(auto a = cast(A)b) ...

The case for dynamic cast is closed. I just heard from the powers that be that std.conv.to will support an exception-throwing dynamic cast in the next Phobos. So it's

    dst = cast(T)src;  // non-throwing dynamic cast
    dst = to!(T)(src);  // throwing dynamic cast

Hopefully everyone's happy now.

Does anyone have a problem with the proposal /apart/ from dynamic cast failure?

Reply to Janice,


> Does anyone have a problem with the proposal /apart/ from dynamic cast
> failure?

no

Dee Girl Wrote:

> In my code I use often capability test.

I see no problem, if you want it, use it.

> Then linear search is fast up to 32 elements. Only then hash is best.

don't forget, with if-else chain you do type check on every element, typecheck is implemented as looping through vtable. With type hashtable you process typeinfo only once, then you search for its hash.

Janice Caron Wrote:

> Hopefully everyone's happy now.
> 
of course, if you're happy, everyone's happy :)

BCS Wrote:

> I guess if you can convince me that I am in the minority here
In fact, I am the only who argued for throwing cast, it seems like everyone else is against my proposal, so the result is obvious.