> The builtin associative arrays of D. i.e.: > > int[string] aa;
I could tell it was a container. Guess this shows how far I'm not looking (or behind) with the details of implementation. > If key, it must be read only, since keys must be immutable. > > If value, it could potentially be read/write. That's what I thought... I'd think keys could be mutable; However the hash would have to be recalculated afterwards. That would be for very rare projects (effectively removing it, adding it back in), but I don't really see it happening. Manually doing it is likely safer and easier to follow. > properties are methods. There should be a way to pass > a delegate to a > property function, not allowing this would be unnecessarily > limiting. > Some sort of __traits directive comes to mind... Yes I know that part. Just go with what makes the most sense. In my mind something should be a property if it doesn't do anything really, and has specific limitations on what it decides to do; Example: A Getter: Like (.length), you get the length/size and that's it. No side effects, no generating new objects (not counting dup) A Setter (or lack of): Returning void (or the object/structure called), May change the structure, but only doing exactly what you expect it to do. I guess more importantly I'd need an example of how passing a method like that to a delegate could be useful. I'd need a reasonable example, not just syntax. The only time that might be useful, like if somewhere in the calling it might change size; But for arrays that can reallocate then you may end up with the old array and not the newer one defeating the purpose. I'll leave whatever decisions to you guys. And I'm glad to see how fast bugfixes have been progressing recently.
