Try yourself.... create an array.... do a loop, look up a load of the, Now use a ds_map, look up a load of them. ds_maps are MUCH slower than simple arrays because it has to do LOADS of work to find each element, where arrays have the index at once. Now if you start doing this, then things like grids and lists where you do sit in loops and process stuff will be adversely affected. I use grids a lot not just for maps etc but for data structures as they are slightly faster than arrays. if this changes, all this code will slow down hugely. My C64 emulator which grids it massively would be a third of the speed. every lookup hit by this - why? Because you can't clear a variable? On the subject of this.... If your passing around list handles and don't check that it's free'd then your still asking for bugs, unless you're going to check it exists every time you use it of course, which is just a waste of CPU time. And this isn't about being stuck in the past, it's about not wasting CPU time on stupid things that will cripple performance in a lot of cases. CPU performance with data structures is the ONLY reason I don't want to change them, it's ALL about performance and how much it would hurt. What a load of tosh. I've hired a lot of them, most of the ones we interview barely know how many bits are in an INT, or even what a "bit" is - I kid you not. There's also a reason I've been in this industry for 27 years, so try not be quite so insulting. Actually...... it IS technically possible that we could (now) turn handles into 64bit numbers (rather than a 32bit INT), as the runner now has proper support for them (I think), and we could store the index in the lower 32bits, and a unique number in the upper 32bits. Then it would just be an AND to get the index back. I'm not sure INT64's are complete throughout the VM yet, but if they are, this might work. let me file this as a suggestion, and in the new year we'll discuss it, because it would solve the problem without crippling everything - but it is totally dependant on the VM internals.