On Wed, 26 Oct 2011 07:38:06 -0400, Steven Schveighoffer wrote: > On Tue, 25 Oct 2011 14:52:57 -0400, Timon Gehr <timon.g...@gmx.ch> > wrote: > >> On 10/25/2011 08:38 PM, Graham Fawcett wrote: >>> On Tue, 25 Oct 2011 13:11:20 -0400, bearophile wrote: >>> >>>> Dmitry Olshansky: >>>> >>>>> No, it's not a bug. It's the same as c++ STL remove - it operates on >>>>> range but not on container. To shrink container, update it's length. >>>> >>>> Thank you for your answer, I didn't know this, and I didn't think >>>> about this possibility because it's weird, it's an in-place operation >>>> that modifies the data only partially, leaving it in a wrong state. >>>> It looks like a bad design, bug prone-too. The design of Python del >>>> is better. (Maybe I'll have to bring this in the main D newsgroup >>>> too, because Phobos bug reports often get unnoticed). In the meantime >>>> I'll add a wrapper function to dlibs2. >>> >>> I think I'd like to see std.array.replaceInPlace grow a >>> three-parameter version, so you could write: >>> >>> replaceInPlace(arr, f, t); // del arr[f:t] >>> >>> ...instead of: >>> >>> replaceInPlace(arr, f, t, cast(typeof(arr)) []); >>> >>> ...and skip the pointless allocation of the empty array. >>> >>> Graham >>> >>> >> There is no allocation, so no significant runtime overhead ( assert([] >> is null); ) > > Note that there *is* overhead, even if it's not significant. I highly > recommend never to use [] and use null instead. > > Does replaceInPlace(arr, f, t, null) work? Perhaps replaceInPlace could > just default the fourth argument to null.
Yes, it works with null, although you have to cast it to typeof(arr). Graham
