Interesting PRs: bringing type system legitimacy to shared allocators

Nick Sabalausky (Abscissa) via Digitalmars-d digitalmars-d at puremagic.com
Mon May 1 09:31:10 PDT 2017


On 04/30/2017 05:39 PM, Andrei Alexandrescu wrote:
> The allocators design is interesting in that it has a full DbI core, on
> top of which resides a thin dynamically-type interface (IAllocator and
> ISharedAllocator). We're still exploring the idioms enabled by this
> interaction. -- Andrei

I assume this dual-interface design (DbI + OO) is, much like std.digest, 
a way to have our template/DbI cake and still permit things to be 
selected at runtime too (via OO), right?

If so, this is a topic that's been on my mind lately, and I'd like to 
offer some thoughts I've had (well, some partial thoughts anyway):

Part A: While I like that the std.digest design allows both DbI and 
runtime-selection of arbitrary user-created types, it has a few issues:

1. It feels awkward that it needs essentially duplicate APIs under two 
different paradigms to pull it off.

2. If a library (such as mine) wants to support both versions, then it 
needs a little bit of extra plumbing to accommodate that. Or at least it 
seemed to in my case. (std.digest itself even has a little bit of extra 
plumbing because of it: WrapperDigest)

3. The OO version, being OO, does involve some type erasure.

Now, fast-forward to:

Part B: On a separate project, I've used Sonke's TaggedAlgebraic before 
<https://github.com/s-ludwig/taggedalgebraic>. It's kind of interesting: 
It's much like Phobos's Algebraic, except it allows function/member 
forwarding to the current underlying value *without* having to 
explicitly check what the current value's type is (Don't recall offhand 
exactly how it handles members that don't exist on the current type, 
probably throws I guess, although I'd imagine it would be possible to 
statically disallow access to members known at compile-time to not exist 
in *any* of the possible underlying types. But I digress).

But then:

Part C: At the time, I saw TaggedAlgebraic's member-forwarding as a 
minor little convenience feature. But the other day I was working with 
some code that used and built upon std.digest, and something occurred to me:

If we had a type similar to TaggedAlgebraic, but was an open variant 
rather than a closed algebraic (Ie, a type like Phobos's Variant, but 
forwarded member access without first requiring explicit conversion to 
the exact underlying type), then *that* could be used to permit 
runtime-selection between arbitrary DbI types *without* the type-erasure 
and "duality" of adding in OO (or at least, less type-erasure anyway). 
Just maybe need the ability to filter the allowable types via a 
constraint (such as isBidirctionalRange, etc), and then, IIUC it should 
be possible for the variant-like supertype to qualify as an 
honest-to-goodness instance of the DbI interface. Voila: OO has been 
obsoleted.

Destroy?



More information about the Digitalmars-d mailing list