Janice Caron Wrote:

> Could you be a bit more specific?

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=71111

my proposal would be to make cast safer
1) throw InvalidCastException on invalid cast
2) keep const

const_cast, dynamic_cast, static_cast, reinterpret_cast templates can be implemented using this safe cast, they can be inefficient and ugly - it's normal, because they normally should not be used.

This will break existing code a little
1) if(auto x=cast(X)y) will probably throw in a predicted location, workaround - when porting, replace cast with dynamic_cast template (which should be provided by standard library for porting legacy code)
2) won't compile if mutability is used - easy to fix.

Reply to terranium,


> 1) if(auto x=cast(X)y) will probably throw in a predicted location,
> workaround - when porting, replace cast with dynamic_cast template
> (which should be provided by standard library for porting legacy code)

The proposed dynamic_cast template, can't be implemented safely and efficiently with the primitives you propose.*

The primitives you propose can be safely and efficiently implemented with the ones Yigal proposed.

*You either get a redundant downcast check, invoke the exception handling system or you need to use reinterpret_cast.

terranium wrote:
> Janice Caron Wrote:
> 
>> Could you be a bit more specific?
> 
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=71111
> 
> 
> my proposal would be to make cast safer 1) throw InvalidCastException
> on invalid cast 2) keep const
> 
> const_cast, dynamic_cast, static_cast, reinterpret_cast templates can be implemented using this safe cast, they can be inefficient and ugly - it's normal, because they normally should not be used.
> 
> This will break existing code a little 1) if(auto x=cast(X)y) will
> probably throw in a predicted location, workaround - when porting,
> replace cast with dynamic_cast template (which should be provided by
> standard library for porting legacy code) 2) won't compile if
> mutability is used - easy to fix.

You want the RTTI cast to throw on error. I'm personally a bit torn here
since on the one hand I do see your point and it is more "clean" for
some examples. on the other hand it adds a performance penalty the
others do not want. Casts shouldn't be normally used and if you do use
them then you should pay the performance price, right?
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.
maybe a helper template like this could be added to the proposal as well
since we already added the reinterpret_cast in a library form too.
so D will have two basic language level constructs and two additional
library helper templates:
built into the language:
cast(T)
cast!(T)
import std.cast for this: [the name is just an example, of course]
reinterpret_cast!(T)
strong_cast!(T) // like cast(T) only throws on error

I don't add this to the "official" proposal yet, this is still just some
thoughts not finalized into anything formal.
feel free to discuss this and propose names for the strong_cast!(T)
template.

terranium Wrote:

> Janice Caron Wrote:
> 
> > Could you be a bit more specific?
> 
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=71111
> 
> my proposal would be to make cast safer
> 1) throw InvalidCastException on invalid cast
> 2) keep const
> 
> const_cast, dynamic_cast, static_cast, reinterpret_cast templates can be implemented using this safe cast, they can be inefficient and ugly - it's normal, because they normally should not be used.
> 
> This will break existing code a little
> 1) if(auto x=cast(X)y) will probably throw in a predicted location, workaround - when porting, replace cast with dynamic_cast template (which should be provided by standard library for porting legacy code)
> 2) won't compile if mutability is used - easy to fix.

Maybe the way it should work is this. The language provides primitives. Library constructs from primitives. But cast that throws is not good primitive. Because you need expensive operation to implement cast that returns null on failure. A better primitive is cast that returns null. You can implement cast that throws in a library.

One more opinion I have. The pattern in Java with if (a isa Type) { Type t = (Type) a; ... } is very clunky. It is not inefficient. Because Java compilers all have special case for the sequence (peephole optimization). But it is verbose programming style with duplication. If you use cast that throws in D then you are forced in that pattern. Another reason cast that throws is not good. Thank you, Dee Girl

Reply to Yigal,

> I don't add this to the "official" proposal yet, this is still just
> some
> thoughts not finalized into anything formal.
> feel free to discuss this and propose names for the strong_cast!(T)
> template.

force_cast!(T)

and I'd put them in object.d

BCS Wrote:

> Reply to Yigal,
> 
> > I don't add this to the "official" proposal yet, this is still just
> > some
> > thoughts not finalized into anything formal.
> > feel free to discuss this and propose names for the strong_cast!(T)
> > template.
> 
> force_cast!(T)
> 
> and I'd put them in object.d

What is object.d please?

Only now I understood something. It was in a early post. There is enforce already in std.contracts. Then enforce(cast(T) x) works. It is longer than force_cast!(T) x. But I prefer it because it respects composition principle. If I know what cast does and what enforce does then I know what enforce(cast(T) x) does. Thank you, Dee Girl

BCS Wrote:

> The proposed dynamic_cast template, can't be implemented safely and efficiently
> with the primitives you propose.*
> *You either get a redundant downcast check, invoke the exception handling
> system or you need to use reinterpret_cast.

this should be deemed as sort of legacy functionality, so it need not to be efficient.

On 13/05/2008, terranium <spam@here.lot> wrote:
>  1) throw InvalidCastException on invalid cast

We already have that.

    import std.conv;

    dst = to!(T)(src);

I quote:

<quote>
The to family of functions converts a value from type Source to type
Target. The source type is deduced and the target type must be
specified, for example the expression to!(int)(42.0) converts the
number 42 from double to int. The conversion is "safe", i.e., it
checks for overflow; to!(int)(4.2e10) would throw the
ConvOverflowError exception. Overflow checks are only inserted when
necessary, e.g., to!(double)(42) does not do any checking because any
int fits in a double.
</quote>

If std.conv.to doesn't do dynamic casting, it can easily be made to, so your base is already covered.

Reply to Dee,

> BCS Wrote:
> 
>> Reply to Yigal,
>> 
>>> I don't add this to the "official" proposal yet, this is still just
>>> some
>>> thoughts not finalized into anything formal.
>>> feel free to discuss this and propose names for the strong_cast!(T)
>>> template.
>> force_cast!(T)
>> 
>> and I'd put them in object.d
>> 
> What is object.d please?

all the stuff that you can't live without like the definition of Object, TypeInfo 'n friends, the Error and Exception class and whatnot.

Reply to terranium,

> BCS Wrote:
> 
>> The proposed dynamic_cast template, can't be implemented safely and
>> efficiently
>> with the primitives you propose.*
>> *You either get a redundant downcast check, invoke the exception
>> handling
>> system or you need to use reinterpret_cast.
>
> this should be deemed as sort of legacy functionality, so it need not
> to be efficient.
> 

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.