After the input I've gotten in this thread I'm currently leaning more towards the cast<type>(expression) syntax.

The cast(type)(expression) syntax doesn't look quite right, and has no advantage over the previous.

The (type)(expression) looks better, but is more complicated to implement, because it will conflict with the (func_ptr)(argument) expression. The ambiguity has to be resolved in the compiler, instead of in the parser, because only the compiler knows if the identifier is a type or a variable.

The <type>(expression) syntax might work. Though it is moving farther away from the C++ syntax.

Going exotic with value->type, or something like it, is definetly out of the question, though I thank you for the suggestion. :)

I was suggesting the cast(type)(expression) syntax to avoid you the trouble of handling a whole new use for the < and > tokens.

I know, and I was actually considering using that syntax before, but after thinking about it some more I decided to use the other.

Implementation wise, there is very little difference between the two, the parser just have to detect a '<' instead of a '('.

I've been meaning to comment on this:

I prefer the cast<type>(value) cast syntax over the rest.

Secondly,

the const_cast, static_cast, etc are useful for several reasons:

1. They provide additional semantics for users and demonstrate that the user is explicitly aware of the type of cast and generally what they expect the cast to be valid for.

2. They are way easier to find: Try creating the reg exp that 100% finds C-style casts, then one that finds C++ casts and tell me what one you finish first =)

I've begun work on this, slowly, but it is a start. Yesterday I implemented the parsing of this new syntax. Took me about 30 minutes to get that working. :)

Ah, I chose the cast<type>(expr) syntax. I wont implement all the C++ cast versions: const_cast, static_cast, reinterpret_cast, and dynamic_cast. At least not unless it becomes really necessary.

Next step is to implement the compiler support.

For primitive types the cast will work as normally, i.e. a static cast based on the known type at compile time.

For class types the cast will be dynamic, returning a null value if the cast cannot be performed. In the future the compiler may also optimize this to perform a static_cast if the type is known at compile time.

Regards,
Andreas