== Quote from Mehrdad (wfunct...@hotmail.com)'s article > > "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.). > Yes, let's introduce immutable_cast(), const_cast(), shared_cast(), > static_cast(), dynamic_cast(), > reinterpret_cast(), sounds like a good idea lol.
Joking aside, I've actually found a few templates to be helpful for casting only one modifier at a time: unconst!(T)(auto ref T value) //Removes const unshared!(T)(auto ref T value) //Remove shared arrcast!(TTo, T)(auto ref T array) //Array cast, keeping const/immutable, doing length divisibility checks, etc. Name is ugly, I couldn't think of anything better Should templates like those be included in std.conv or something?
