Jarrett Billingsley wrote: > On Tue, Feb 24, 2009 at 8:23 PM, Daniel Keep > <daniel.keep.li...@gmail.com> wrote: > >> Yup. >> >> It's a pity that we don't have, oh I don't know, some sort of efficient >> iterable interface that doesn't cause a heap allocation that the runtime >> could use instead *cough*hint*cough*andrei*cough*ranges*cough*. > > You can use "foreach(k; aa)" and "foreach(_, v; aa)". > > The thing is they're not always substitutes for .keys and .values. > For example, if you want to modify the AA during the foreach loop, you > have to use something like "foreach(k; aa.keys)" since you need a > "snapshot" of the keys as they were before you started modifying it.
True; although I'm one of those people who stays up at night, plotting the gruesome demise of invisible allocations, so I tend to do manually create and destroy the storage for the keys. In a perfect world, we'd have extension methods, and then we could just do this: RangeType!(T)[] toArray(T)(ref T this) if isRange!(T) { ... } foreach( k ; aa.keys.toArray ) ... My own policy is that if you have to choose between two designs, one where you always allocate and the other where you can optionally allocate, go for the second. -- Daniel