Benji Smith: > Especially since an associative array should have a .keys property that > returns a set.
I don't agree. I think associative arrays should have .keys/.values/.items that return a lazy view that acts like a .set/.list/.list of pairs. Such "lazy views" don't actually store anything, they are very light. This design is now present in Python3, Java and I have done very similar things in my dlibs (named xkeys/xvalues/xitems in my dlibs, but xkeys isn't a set-like thing yet). > (Incidentally, I also think the natural set operations, like > intersection and mutual exclusion, are just as handy for maps as for sets.) It's less semantically clean to define certain set operations on AAs, because for example you have to decide what to do when keys are equal but their values are not. You can avoid such semantic troubles altogether performing set operations just only on the lazy view of the keys. > The natural conclusion is that AAs should be library types. I agree that probably now it's better to keep built-in only the syntax of AAs and keep their semantics into D modules code. But I think what we/I have discussed here doesn't imply such conclusion :-) I think you can do all the things I have explained here even with a fully built-in. I'm waiting for a more community-driven design of D ;-) Bye, bearophile
