Jonathan M Davis:

> Personally, I find the added complexity of C++'s special casts to _far_ outweight what benefit they give you.

I don't want to copy C++, I prefer casts better designed than C++ ones, and probably they don't need language-level support. I'd like a cast to cast enums safely, to be integrated into to!(). A StaticObjCast just for statically and safely cast object references. One cast to change the const status of a type const <-> immutable <-> mutable. I'd like to keep unqual and to!(). dynCast is better explicit, because it has a not small runtime cost, and its purpose is quite different from other casts, so such differences are worth showing visually too.

Bye,
bearophile

On 2011-06-03 05:14, bearophile wrote:
> Jonathan M Davis:
> > Personally, I find the added complexity of C++'s special casts to _far_ outweight what benefit they give you.
> 
> I don't want to copy C++, I prefer casts better designed than C++ ones, and probably they don't need language-level support. I'd like a cast to cast enums safely, to be integrated into to!(). A StaticObjCast just for statically and safely cast object references. One cast to change the const status of a type const <-> immutable <-> mutable. I'd like to keep unqual and to!(). dynCast is better explicit, because it has a not small runtime cost, and its purpose is quite different from other casts, so such differences are worth showing visually too.

And I would argue that the fact that you have separate casts in the first place is 90% of the problem. Sure, you could design the casts better, but having to deal with more than one type of cast is the core of my complaint in the first place. I find it to be very annoying and of little value.

- Jonathan M Davis

On 01/06/2011 21:51, Steven Schveighoffer wrote:
> On Wed, 01 Jun 2011 16:38:42 -0400, KennyTM~ <kennytm@gmail.com> wrote:
<snip>
>> cast(const), cast(immutable) etc are documented. cast() is not. See
>> http://d-programming-language.org/expression.html#CastExpression

What is that site?  A reference for how the compiler actually behaves, as opposed to the spec?

> :O
>
> Of course, by documented, it shows the cast in the grammar (BTW, why the separate rule for
> cast(Type) when CastParam can be Type?), but not in the text. I almost never read the
> grammar unless I'm confused by the docs.
>
> This is almost as good as const_cast, although it seems too easy to screw up and remove
> const when you don't want to.

And it's a puzzling notation.  Nobody would guess what it means.  As such, it looks like a bug that the compiler accepts the code.

See also previous discussions about making casting away const/immutable explicit:
http://tinyurl.com/4x7wpy9
http://tinyurl.com/4xotq3o

Stewart.

On 2011-06-03 16:33, Stewart Gordon wrote:
> On 01/06/2011 21:51, Steven Schveighoffer wrote:
> > On Wed, 01 Jun 2011 16:38:42 -0400, KennyTM~ <kennytm@gmail.com> wrote:
> <snip>
> 
> >> cast(const), cast(immutable) etc are documented. cast() is not. See
> >> http://d-programming-language.org/expression.html#CastExpression
> 
> What is that site? A reference for how the compiler actually behaves, as opposed to the spec?

d-programming-language.org is the site that is going to become the main site for D. It's not quite far enough along to replace the portions of www.digitalmars.com on D, but once it is, a lot of the stuff which is currently on www.digitalmars.com will redirect to d-programming-language.org.

- Jonathan M Davis