Library associative array project v0.0.1

Steven Schveighoffer schveiguy at gmail.com
Thu May 12 17:46:19 UTC 2022


On 5/12/22 1:15 PM, H. S. Teoh wrote:
> On Wed, May 11, 2022 at 11:31:02AM -0400, Steven Schveighoffer via Digitalmars-d-announce wrote:
>> I just spent a couple hours making a library AA solution that is
>> binary compatible with druntime's builtin AA.
> 
> This is awesome!  Don't have time to look at it in detail right now, but
> will definitely keep this in mind.
> 
> 
>> The benefits:
>>
>> 1. Proves that a library implementation is possible, also shows where
>> shortcomings are.
> 
> What are the shortcomings that you found?

I mean it has the benefit of highlighting where the language doesn't 
provide the capability of replacing the existing AA with a library type. 
I literally threw this together in a few hours, so I haven't used it or 
tested it a lot. I know there are *some* things, but I haven't tried yet 
to exhaustively make it a drop-in replacement.

I was surprised at how short the code is once you throw out all the 
TypeInfo BS that is currently in druntime.

>> For the future:
>>
>> 1. Implement all the things that AAs can do (which are possible, some
>> are not).
> 
> Which things are not possible to do?

The whole thing how the compiler knows that an outer AA is being used to 
initialize an inner AA.

e.g. this works currently, but is impossible to hook for a library (I 
think):

```d
int[int][int] aa;
aa[0][1] = 5;
```

There's also possible problems with qualifiers that are 
yet-to-be-discovered, but usually show up when the compiler is cheating.

>> 2. Look at alternatives to GC for allocation/deallocation.
>> 3. Possible use with betterC?
> [...]
> 
> Just use malloc/free?  Could have problems with dangling references to
> buckets, though, if somebody retains the pointer returned by `key in
> aa` expressions.  Or use ref-counting of some sort.  But hard to do this
> without changing binary compatibility.

Yes, the lifetime issues are the real problem with not using the GC. 
Maybe you just avoid the `in` operator in those flavors? Instead you can 
use a match-style operation, something like:

```d
hash.match(k, (ref v) {
   // work with v
});
```

The whole point of this "exercise" is to see what is missing, and 
explore what is possible.

-Steve


More information about the Digitalmars-d-announce mailing list