Accidentally killing immutable is too easy in D (Was: cast()x - a valid expression?)

[Jonathan M Davis]

On 2011-06-02 09:02, Bruno Medeiros wrote:
> 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.

Really, you should only be using casts when you need a cast, and you should be 
careful when you use them. So, you have to know what you're doing and why in 
that particular instance and not use them willy-nilly. In most code, casts 
should be quite rare. If you're doing a lot of low-level stuff, then they 
might be more common, but in general, they're a sledgehammer that shouldn't be 
used except when you really need them.

> 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.).

I really don't know what you'd do other than introducing stuff like C++'s 
const_cast, and I know very few programmers who actually use any of those 
special casts. In most cases, they just use C-style casts. It just gets too 
complicated to determine what the correct cast to use in a particular 
situation is. And C++ is the only language I know of with more than one type 
of cast. I think that it's _far_ better to have the compiler figure that out 
for you. Some templates could be created for changing one aspect of type (such 
as mutability or shared-ness) if people really want that, but since casts 
should generally be rare in the first place, the effort of getting them right 
shouldn't be very high anyway. Regardless, I'd _hate_ to see the built-in cast 
operator altered to be more complicated. I _much_ prefer it to C++'s special 
casts, and I'm _very_ glad that they were not one of the C++ features to be 
carried over to D.

- Jonathan M Davis