On 2008-May-27, at 8:32 pm, Jon Lang wrote:
[...] Would it be reasonable to allow hashes to use .[] syntax as something of a shortcut for ".iterator in list context", thus allowing autosorted hashes to partake of the same sort of dual cardinal/ordinal lookup capabilities that lists with user-defined array indices have?
I thought it already did, but apparently it's something that we discussed that didn't actually make it into S09. I agree that .[] should apply to hashes just as .{} can apply to arrays. The hashes don't even need to be sorted -- %h[$n] would basically be a shorter way of saying @(%h.values)[$n], in whatever order .values would give you.
Side issue: S09 doesn't specify whether or not you need to explicitly declare a hash as autosorted. I'm assuming that the parser is supposed to figure that out based on whether or not .iterator is ever used; but it isn't immediately obvious from reading the "Autosorted hashes" section. As well, there might be times when explicitly declaring a hash as autosorted (or not) might be useful for optimization purposes.
Does the parser need to know? All hashes have an .iterator method, but you can override it to force elements to be returned using some particular ordering.
Providing a flag for optimisation sounds useful... although since Perl doesn't do any sorting for you, if you want something more optimised than making .iterator re-sort the hash every time it's called, you'd have to replace the innards of the Hash type yourself anyway. But if you did make a Hash::Sorted class, defining an "is sorted" trait might be a nice way to use it.
-David
