If you had money to place for a bounty, what would you choose?

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Nov 28 15:33:09 PST 2013


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.


More information about the Digitalmars-d mailing list