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
