since the other thread got completely off-topic and lost any connection to the original discussion, here's a new clean thread, that will hopefully summarize the previous discussion and present the latest proposal so that hopefully more people join the debate without the need to go through all the previous posts (164 posts!).

Here goes:

the proposal is for a safer cast that will _replace_ the current cast. this is important both for a consistent syntax and to prevent subverting the system with the old style cast.

there are there forms of cast:
(a) cast(T)something
(b) cast!(T)something
(c) reinterpret_cast!(T)

there is no need for language support for (c) since this can be implemented via a union and this is exactly what this library template does. the only reason for this is to have a standardized name. unless the user really knows what he's doing this should be avoided, since this is the most dangerous form of cast.

goals of this design:
1. you can search/grep for all casts in your code.
2. constancy is cast explicitly so no more casting an invariant T to a
mutable U in one cast. this prevents bugs.

(a) will do would you'll expect in the common case. while (b) is for
more "dangerous" casts. it can also be defined in all forms
(implicit/explicit) by the user while (b) isn't.

if T is a class then (a) uses RTTI cast (down casting) or a user defined
conversion, otherwise (a) will do plain conversions like the current
cast does.
(b) is used for constancy casts and the specific use case of casting
pointers to void. (more specific cases could be added in the future)

for c++ people this translates to:
(a)  (T is a class) ? dynamic_cast : static_cast
(b)  const_cast
(c)  reinterpret_cast implemented in library

also note that cast(T) for classes will return null on failure  just
like in current D.

questions?

Reply to Yigal,
> 
> questions?
> 

looks good. Excluding the Const stuff (and I've been ignoring all that for months) it seems consistent and reasonably compact. As for the Const stuff, I'll let others pass jugment.

On 13/05/2008, BCS <ao@pathlink.com> wrote:
>  looks good. Excluding the Const stuff (and I've been ignoring all that for
> months) it seems consistent and reasonably compact. As for the Const stuff,
> I'll let others pass jugment.

Obviously, since I was partly involved in drafting this, I support it.

Basically what this means is that, once the change is made, 99% of your code will compile, and maybe 1% wont. (I'm making these numbers up, by the way, just for illustration).

So you look at the lines the don't compile, and ponder "Is this a bug, or is it correct?". If you decide it's correct, you change "cast" to "cast!" and recompile, and all should be well.

If it /still/ doesn't compile, it's almost certainly a bug in your code. But not neccesarily, because there's still a chance you /might/ be doing two things at once, in which case, if you're really, really sure it's not a bug, you change your code from "cast!(T)" to "cast!(T)cast(U)", where U is some intermediate type (so the safe cast changes the type but not the constancy, and then the danger cast then changes the constancy). Now it should compile.

And if it /still/ doesn't compile, it's either a bug or very badly designed code. In the latter case, you can use reinterpret_cast!(T) to force the line to compile.

Simply put - this is a tool for finding bugs at compile time. Without this, those bugs could bring your program crashing down at run time. So yes, I love this idea.

Yigal Chripun Wrote:

> also note that cast(T) for classes will return null on failure  just
> like in current D.

I don't think that such redesing is useful.

On 13/05/2008, terranium <spam@here.lot> wrote:
> I don't think that such redesing is useful.

Could you be a bit more specific?

Personally I think finding bugs is /very/ useful, especially since all that is really being asked of the programmer is an exclamation mark.

Yigal Chripun Wrote:

> 
> there are there forms of cast:
> (a) cast(T)something
> (b) cast!(T)something
> (c) reinterpret_cast!(T)
> 

> questions?

My only concern is the re-use of '!'.

My first thought on reading your proposal was that 'cast!(T)' was some sort of template. I'm sure with a little practice I could get to where I immediately recognize it as a dangerous(!) cast, but it's just one more thing to learn.

From my cursory examination of keyword usage I've concluded that the keywords that are problematic ('const', 'enum') are the ones that mean different (but related) things in different usages. I'm not at all convinced that parsimony in keywords is a good thing, but that seems to be a minority view (and it isn't Walter's view, as far as I can tell).

We're a little more accustomed to re-definition of symbols, especially in a new context, but this isn't new -- it's a variable name followed by a '!'.

Having said that, I don't have an alternative notation. Perhaps a long keyword llike 'const_cast', 'invariant_cast', etc., similar to the 'reinterpret_cast' usage.

I do think it's a good idea, though to have the separate types of casts called out.

Paul

Paul D. Anderson wrote:
> Yigal Chripun Wrote:
> 
>> there are there forms of cast: (a) cast(T)something (b)
>> cast!(T)something (c) reinterpret_cast!(T)
>> 
> 
>> questions?
> 
> My only concern is the re-use of '!'.
> 
> My first thought on reading your proposal was that 'cast!(T)' was some sort of template. I'm sure with a little practice I could get to where I immediately recognize it as a dangerous(!) cast, but it's just one more thing to learn.
> 
> From my cursory examination of keyword usage I've concluded that the keywords that are problematic ('const', 'enum') are the ones that mean different (but related) things in different usages. I'm not at all convinced that parsimony in keywords is a good thing, but that seems to be a minority view (and it isn't Walter's view, as far as I can tell).
> 
> We're a little more accustomed to re-definition of symbols, especially in a new context, but this isn't new -- it's a variable name followed by a '!'.
> 
> Having said that, I don't have an alternative notation. Perhaps a long keyword llike 'const_cast', 'invariant_cast', etc., similar to the 'reinterpret_cast' usage.
> 
> I do think it's a good idea, though to have the separate types of casts called out.
> 
> Paul

to my defense, I'll note the fact that c++ provides its casts (except of
course the legacy C syntax) with a template syntax too, even though they
 don't have to be implemented in terms of templates. You can ask Walter
how it's implemented in DMC. and it has some similarity in meaning as
well, in a way it does behave like a template since the output is
parametrized on the input type T. even though the cast isn't really a
template, i think that both meanings are suitable here.
look at it like this:
cast(T) has similarities with a function in that it's make runtime
checks for an RTTI cast for example, or behaves like a function that
converts a value to a different type.
the cast!(T) on the other hand is more in the realm of the static world
of the compiler. it doesn't do all the checks the cast(T) does and in a
way is more low-level.

the reinterpret cast is a special case. it's very unsafe and very low-level and I wouldn't even provide it at all in the proposal since the experienced OS writer (as an example) which needs this feature can implement it himself via unions. the only benefit of providing it in the library is to have a standardized name for it. it should be discouraged and accompanied with warnings in the docs. since D is a Systems programming language, it's still possible to use it, only you need to be damn sure you know what you're doing when subverting the type system like that.

I've just thought of an analogy to explain the different cast types: [take this with a grain of salt, it's not meant to be discussed seriously]

casts are like doom cheats. the ones we used in doom 2 when we were just kids with a 486 computer. (my first real PC. I had a 386 which broke down after a few months which was then replaced to this model)

cast(T) gives you a one time bonus amount of ammo. in a very hard level
this can be understandable.
cast!(T) give you 150% health. this is a much more serious cheat which
in multi-player mode would be frowned upon unless everyone apply the
same cheat, of course ;)
reinterpret_cast!(T) is god mode and no one will want to play with you
like that. this is serious cheating you'll only use in single-player mode.

I'm sure I can Google the actual codes for those cheats ;) the must be documented somewhere...

--Yigal

Yigal Chripun, el 13 de mayo a las 15:58 me escribiste:
> since the other thread got completely off-topic and lost any connection to the original discussion, here's a new clean thread, that will

It's generally a better idea to keep the original thread topic and start a new one with the new topic, because this way you have the (already polluted) "safer casts" thread splitted in 2 threads, making even more difficult to follow it.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Corrí muchas carreras, tratando de alcanzarte a vos.
Pero corría sólo y siempre salí último.

Leandro Lucarella wrote:
> Yigal Chripun, el 13 de mayo a las 15:58 me escribiste:
>> since the other thread got completely off-topic and lost any connection to the original discussion, here's a new clean thread, that will
> 
> It's generally a better idea to keep the original thread topic and start a new one with the new topic, because this way you have the (already polluted) "safer casts" thread splitted in 2 threads, making even more difficult to follow it.
> 

come on, that's just hindsight.
I agree of course that one thread for the topic is better than two, but
since we are already in a situation with a thread that contains about
170 posts most of which are off topic, a new clearly named thread
("safer cast -take II" clearly suggests what the content is IMO) is
better than just continue posting in the older thread. what else do you
want me to do?? Go back in time and repost in a different thread??

since we already have one polluted (huge) thread I do not wish to
discuss this here further, if you want, you can mail me personally and
continue this discussion there  (although i don't see a reason to do this)

now, back on topic! what's your opinion on the proposal? please share your thoughts for the betterment of the D community.

--Yigal