"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.527.1306962732.14074.digitalmars-d@puremagic.com...
> On 2011-06-01 13:42, Nick Sabalausky wrote:
>>
>> It's nice in a way, but it's all based on the way cast handles modifiers.
>> And I've always been a bit unconfortable with how that's handled (In
>> fact,
>> I was just thinking about this yesterday). Specifically, it seems
>> extremely bad that it's so incredibly easy to accidentaly cast away
>> things
>> like const and immutable:
>>
>> For example, if I know I have an array of uint's, and I want to deal with
>> the individual bytes, it's perfectly safe and sensible to cast it to a
>> ubyte[] (a long as you factor in endianness, of course). So, you do
>> "cast(ubyte[])myArray". But, OOPS!!: If myArray happened to be immutable,
>> then merely trying to cast the type has inadvertantly cast-away
>> immutable.
>> Not good! Casting away const/immutable really, really should have to be
>> explict.
>>
>> Of course, you can probably use some fancy helper templates to make sure you preserve all modifiers. But needing to do so is just asking for mistakes: it seems like a huge violation of "make the right way easy, and the wrong way hard".
>
> You really shouldn't be casting much anyway. It's the sort of feature
> where
> you're only supposed to use it when you know what you're doing when you
> use
> it.

Well, when you're doing low-level stuff, type casting tends to be commonly needed. And also when dealing with OO class hierarchies. Problem is, like bearophile said, those uses are typically orthogonal to constness and immutability. It's nice that D's cast is multi-purpose, but I don't like that it's so easy to conflate the purposes of changing the modifiers and changing the base types since you're usually just trying to do one or the other.

If we can change *just* the modifier with cast(immutable), cast(const) and cast(), without touching the base type, then that's fantastic. Certainly very useful. But it's equally useful (maybe even more useful due to the severe danger of casting to/from immutable), to similarly have a way to change just the base type without touching the modifier. Both of these "just one or the other" forms should be the typical usage of cast in 99+% of cases.

> And if there's really any possibility that you're dealing with immutable,
> perhaps you should be casting to const rather than mutable. Personally, I
> find
> how C++ created multiple types of cast (include const_cast) _highly_
> annoying
> and generally useless, and I'm _very_ glad that D didn't do anything of
> the
> sort.
> 

On 6/1/2011 1:05 PM, Steven Schveighoffer wrote:
> When will dmd decide that human life is a disease to be eradicated? When will
> the world be dominated by constinators?!!! I fear for my children.


I cannot allow human error to jeopardize the mission.

Stroustrup: What happen ?
Meyers: Somebody set up us the bomb.
Spolsky: We get signal.
Stroustrup: What !
Spolsky: Main screen turn on.
Stroustrup: It’s you !!
Bright: How are you gentlemen !!
Bright: All your base are belong to us.
Bright: You are on the way to destruction.
Stroustrup: What you say !!
Bright: You have no chance to survive make your time.
Bright: Ha ha ha ha …

On 6/1/2011 5:46 PM, Andrej Mitrovic wrote:
> Stroustrup: What happen ?
> Meyers: Somebody set up us the bomb.
> Spolsky: We get signal.
> Stroustrup: What !
> Spolsky: Main screen turn on.
> Stroustrup: It’s you !!
> Bright: How are you gentlemen !!
> Bright: All your base are belong to us.
> Bright: You are on the way to destruction.
> Stroustrup: What you say !!
> Bright: You have no chance to survive make your time.
> Bright: Ha ha ha ha …

Update - Bright was infected with human error. He has been replaced by the D-9000 computer system.

Nick Sabalausky Wrote:

> Of course, you can probably use some fancy helper templates to make sure you preserve all modifiers. But needing to do so is just asking for mistakes: it seems like a huge violation of "make the right way easy, and the wrong way hard".

Relevant: http://d.puremagic.com/issues/show_bug.cgi?id=5307

Using to!() should not allow removal of qualifiers

"Andrej Mitrovic" <andrej.mitrovich@gmail.com> wrote in message news:mailman.529.1306975584.14074.digitalmars-d@puremagic.com...
>Stroustrup: What happen ?
>Meyers: Somebody set up us the bomb.
>Spolsky: We get signal.
>Stroustrup: What !
>Spolsky: Main screen turn on.
>Stroustrup: It’s you !!
>Bright: How are you gentlemen !!
>Bright: All your base are belong to us.
>Bright: You are on the way to destruction.
>Stroustrup: What you say !!
>Bright: You have no chance to survive make your time.
>Bright: Ha ha ha ha …
>

I don't care how old it is in "internet meme" time: I'll never get tired of those classic lines :)  ('course it's much older than even that...)

On 6/1/2011 12:22 PM, KennyTM~ wrote:
> But this is not documented in the D spec (CastParam cannot be empty). Is this an
> "accept-invalid" bug, or just a feature not yet documented?

A feature that coincidentally just got documented :-)

On Thu, 02 Jun 2011 01:32:52 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 6/1/2011 12:22 PM, KennyTM~ wrote:
>> But this is not documented in the D spec (CastParam cannot be empty). Is this an
>> "accept-invalid" bug, or just a feature not yet documented?
>
> A feature that coincidentally just got documented :-)
>

Seems incorrect:

Casting to a CastQual adds the qualifier to the type of the UnaryExpression.

Casting to the empty ( ) has the effect of removing any top level const or immutable type modifiers from the type of the UnaryExpression.

From these descriptions, I would expect the following asserts to pass:

const int a;
auto b = cast(shared)a; // add shared to the type
assert(is(typeof(b) == shared const int));

shared const int x;
auto y = cast()x; // remove const or immutable from the type
assert(is(typeof(y) == shared int));

But both fail.  Seems like both expressions set the modifiers to their args.

-Steve

On 02/06/2011 06:08, Nick Sabalausky wrote:
> "Andrej Mitrovic"<andrej.mitrovich@gmail.com>  wrote in message
> news:mailman.529.1306975584.14074.digitalmars-d@puremagic.com...
>> Stroustrup: What happen ?
>> Meyers: Somebody set up us the bomb.
>> Spolsky: We get signal.
>> Stroustrup: What !
>> Spolsky: Main screen turn on.
>> Stroustrup: It’s you !!
>> Bright: How are you gentlemen !!
>> Bright: All your base are belong to us.
>> Bright: You are on the way to destruction.
>> Stroustrup: What you say !!
>> Bright: You have no chance to survive make your time.
>> Bright: Ha ha ha ha …
>>
>
> I don't care how old it is in "internet meme" time: I'll never get tired of
> those classic lines :)  ('course it's much older than even that...)
>
>


O RLY? :P


-- 
Bruno Medeiros - Software Engineer

On 01/06/2011 22:12, Jonathan M Davis wrote:
>> It's nice in a way, but it's all based on the way cast handles modifiers.
>> >  And I've always been a bit unconfortable with how that's handled (In fact,
>> >  I was just thinking about this yesterday). Specifically, it seems
>> >  extremely bad that it's so incredibly easy to accidentaly cast away things
>> >  like const and immutable:
>> >
>> >  For example, if I know I have an array of uint's, and I want to deal with
>> >  the individual bytes, it's perfectly safe and sensible to cast it to a
>> >  ubyte[] (a long as you factor in endianness, of course). So, you do
>> >  "cast(ubyte[])myArray". But, OOPS!!: If myArray happened to be immutable,
>> >  then merely trying to cast the type has inadvertantly cast-away immutable.
>> >  Not good! Casting away const/immutable really, really should have to be
>> >  explict.
>> >
>> >  Of course, you can probably use some fancy helper templates to make sure
>> >  you preserve all modifiers. But needing to do so is just asking for
>> >  mistakes: it seems like a huge violation of "make the right way easy, and
>> >  the wrong way hard".
> You really shouldn't be casting much anyway. It's the sort of feature where
> you're only supposed to use it when you know what you're doing when you use
> it. And if there's really any possibility that you're dealing with immutable,
> perhaps you should be casting to const rather than mutable. Personally, I find
> how C++ created multiple types of cast (include const_cast)_highly_  annoying
> and generally useless, and I'm_very_  glad that D didn't do anything of the
> sort.
>
> - Jonathan M Davis

"you're only supposed to use it when you know what you're doing when you use it"
Well, that's kinda the requirement for any feature, isn't it?... :P Well, kinda, I do know what you mean. Yes, one needs to properly learn how cast() works, but that doesn't mean it would not be better for the feature to be designed in a way that is easier to learn (and just as powerful to use), or actually, it doesn't mean that even if you do know how cast() works, that you are not still likely to make a mistake when using it.

So pretty much I agree with Nick here. I think me and a few others have mentioned it in the past, that the way cast works makes it somewhat easy to trip over one's foot and cast away something that was not intended. This may be a bit more common now and in the future as people use more and more of the newer D modifiers (shared, immutable, etc.).

-- 
Bruno Medeiros - Software Engineer