On Tue, 25 Oct 2011 20:52:57 +0200, Timon Gehr 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); )
Ah, my mistake; that makes sense. > I can see how the functionality of the overload would be useful, but I > think it should get a more descriptive name as there is no more > parameter that specifies with what to _replace_ arr[f..t] with. > removeInPlace? Good point -- that would get my vote. Got time for a pull request? :) Graham
