Yigal Chripun Wrote:

> You want the RTTI cast to throw on error.
> it adds a performance penalty

I don't think so. How does it add a performance penalty?

> this current proposal suits everyone in that you can simply define a template my_cast that will call the cast(T) operator and on null will throw an exception.

There is no need for proposals to implement such a template. My reason is to force people to use safe cast, if you just write safe cast with template function, ugly syntax, ugly name, performance penalty (additional check for null) - no one will use it, even I.

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.

> 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.

BCS Wrote:

> As far as I'm concerned it's still an open question if the dynamic_cast or force_cast (by whatever name) will be used more often. So I don't see how you can call it legacy.

Legaciness has nothing to do with frequency of use. I believe, legacy code is used more often, in fact, you're right here. Windows ANSI API is a good example. Total commander... :) Windows itself has workarounds for bugs in MS Office...

Reply to terranium,

> BCS Wrote:
> 
>> As far as I'm concerned it's still an open question if the
>> dynamic_cast or force_cast (by whatever name) will be used more
>> often. So I don't see how you can call it legacy.
>> 
> Legaciness has nothing to do with frequency of use. I believe, legacy
> code is used more often, in fact, you're right here. Windows ANSI API
> is a good example. Total commander... :) Windows itself has
> workarounds for bugs in MS Office...
>

So you are saying that the non-throwing cast should be treated as "the way we did it before we knew better"? If you want to go that way, in order to convince me, you will need to demonstrate a better way. So far no one has.

Reply to terranium,

> There is only minor need for this silent cast, I believe, so 1) since
> this is rarely needed, performance penalty is acceptable,

by that augment, "there is only minor need for /down/ casts, I believe, since" the throwing kind is even rarer than the non throwing kind. In my experience that is the case.

(note: paraphrased to draw attention to the parallel nature of the counter argument)

> The type switch from your example can be implemented
> in a more efficient way with a type hashtable.
>

I'm not seeing it, example please?

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

BCS Wrote:

> I'm not seeing it, example please?

void foo(T arg)
{
  auto handle=myhashtable[arg.classinfo];
  //handle can be data or delegate for increased functionality
}

Reply to terranium,

> BCS Wrote:
> 
>> I'm not seeing it, example please?
>> 
> void foo(T arg)
> {
> auto handle=myhashtable[arg.classinfo];
> //handle can be data or delegate for increased functionality
> }

Where would the table be set up? for delegates to work you would need to set up the table every time the function is called (to get the context pointer right). The next best thing would be something like this:

switch(myhashtable[arg.classinfo])
{
 case ClassEnum: ...
}


but then we might as well let switch take a classinfo struct and avoid the enum. But that looks just plain ugly.

terranium Wrote:

> BCS Wrote:
> 
> > I'm not seeing it, example please?
> 
> void foo(T arg)
> {
>   auto handle=myhashtable[arg.classinfo];
>   //handle can be data or delegate for increased functionality
> }

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

Reply to terranium,

> 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=digitalmar
> s.D&article_id=71729
> 

Yes, I see a bigger need for that than for the throwing kind.

I guess if you can convince me that I am in the minority here you might have something, but just saying you never use them won't do it.