Are associative arrays stable in D?

[Jonathan M Davis]

On Wednesday, July 17, 2013 19:21:03 Yota wrote:
> On Wednesday, 17 July 2013 at 09:48:06 UTC, monarch_dodra wrote:
> > I find it disturbing that the built-in property "keys" would
> > dup an entire array, and then copy all the keys into that
> > array, whereas the function "byKeys()" will simply allow you to
> > iterate on the keys.
> > 
> > "keys" is in blatant violation of the "properties emulate
> > members" mind-set.
> 
> My sentiments exactly. I feel it would also be more appropriate
> to name it 'getKeys'.
> 
> I get the feeling that a lot of methods in Phobos use @property
> just because they can, and it makes me itch when I come across
> them. 'dup' and 'idup' are big offenders. Can't wait to get a
> debugger that visualizes data, and tries to fetch both 'dup'
> properties of a multi-megabyte array. Of course there's no way
> to undo that now without breaking absolutely EVERYONE's code.

It should be noted that keys, dup, and idup are all built-in language features 
and have nothing to do with Phobos. They all pre-date @property by a 
significant margin. The use of @property in Phobos that's particularly stupid 
that I can think of off the top of my head is save for ranges. I don't know how 
Andrei ever thought that that made sense as a property rather than a normal 
function. But in general, I think that Phobos does a good job with @property.

It should also be noted that the line between property functions and normal 
functions is blurred by the fact that empty parens on a function call are 
optional. So, even if dup and idup were normal functions, they'd still 
probably get called all over the place without parens. At this point, assuming 
that the lack of parens means that something is a property is not a good idea. 
You pretty much have to go off of the names and what they do, in which case, 
unless the functions are badly named (like keys), it should be pretty obvious 
what is and isn't a property (at least in concept) in most cases.

On a side note, I'd consider it a major misfeature for a debugger or IDE to 
assume that it can call @property functions any more than it can call normal 
functions. Even if they shouldn't, they can have side-effects and do 
arbitrarily complex operations, since ultimately they're just normal 
functions. Not to mention, plenty of folks are likely to just not bother with 
@property and just call their functions without parens. @property's main value 
is likely to ultimately be in handling the corner cases where optional parens 
cause problems (like returning a delegate) and you want to treat the function 
as a property. It just won't matter for a lot of functions.

- Jonathan M Davis