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?
