On Thu, Nov 28, 2013 at 11:06:41PM +0100, Fra wrote: > On Thursday, 28 November 2013 at 21:38:12 UTC, H. S. Teoh wrote: > >If I had the money, I'd not just place a bounty, I'd hire a team of > >dedicated programmers to work full-time to fix the current AA > >implementation, once and for all. There are at least 76 AA-related > >issues[1] on my list, many of which are not just trifling bugs but > >fundamental design issues. > > How much would it take? Really, it looks like a few monts of > man-work, maybe even a year?
The thing is, it *looks* relatively manageable on the surface, but the more you get into it, the more you realize how fundamentally and irreparably broken it really is. One of the most problematic things is that its implementation is sprinkled throughout DMD (each bit interacting in intricate ways with its surroundings), object_.d (a sort of hybrid half-user, half-built-in struct AssociativeArray), and aaA.d (the core runtime implementation). Each of these pieces interact in complex ways with each other, and don't always share the same information together. My favorite gripe is how struct AssociativeArray knows about the compile-time types of keys and values, but aaA.d has no direct access to that information except via the TypeInfo of the key, passed in at runtime... but it *doesn't* know anything about the *value* type except as an opaque block of bytes, so for example storing value types with non-default .init values does not initialize it correctly -- but most of the time the problem doesn't show up because when you write aa[x]=y, the wrong default initial value gets overwritten by y, which presumably is initialized correctly. But should you write aa[x]++ instead, then the problem suddenly pops up its head. Not to mention, anything involving type qualifiers like const or immutable are horribly broken except for the simplest cases, and are so fundamentally broken it would take a complete rewrite to get it right. To even begin to do anything about this mess, the team has to thoroughly understand dmd internals, aaA.d, and struct AssociativeArray. Then they have to figure out how to extricate the AA-dependent parts of dmd out of all the places they're sprinkled in, *without* breaking the rest of the language, so that a proper library replacement can be put in its place. (Not to mention that said replacement must be 100% compatible with existing D code, lest hordes of angry users knock down your door -- not a trivial task given the current quirks of AA.) And all the while dmd receives a continuous stream of pull requests every day, so when it's all finally said and done, you'll have a veritable nightmare resolving the conflicts when you merge all the inevitable large-scale changes back to git HEAD. It's not an insurmountable task, of course. But it's not gonna get done with a few scattered volunteer hours here, a few minutes of spare time there. You need a dedicated team of coders actively working on it continuously to get through it all. T -- This is not a sentence.
