Tricky semantics of ranges & potentially numerous Phobos bugs

Philippe Sigaud philippe.sigaud at gmail.com
Tue Oct 16 14:00:18 PDT 2012


On Tue, Oct 16, 2012 at 9:41 PM, H. S. Teoh <hsteoh at quickfur.ath.cx> wrote:
> On Tue, Oct 16, 2012 at 09:21:18PM +0200, Jonathan M Davis wrote:
> [...]
>> We'd probably need to add a function to the standard library (e.g.
>> deepCopy) which would be defined for all built-in types and which
>> user-defined types could define (with something hasDeepCopy being
>> there to check for it), and then code could use that for doing deep
>> copies. So again, it's possible, but it doesn't currently exist.
> [...]
>
> I think with D's compile-time introspection capabilities, it _should_ be
> possible to implement a generic deepCopy template that works for any
> type.

I agree. Heck, IIRC I posted a putative deep copy code here some years
ago. Today's Phobos and __traits and the recently improved is()
expression would make that even easier.
After all, any (aggregate) value in D can be decomposed into smaller
parts, until the algorithm finds a leaf/terminal: either a value type
or an array of value types.


> Of course, then one has to address tricky issues such as complex data
> structures that have interlinking parts; a blind recursive deep-copy may
> not have the desired effect (e.g., if we're deep-copying a graph and
> there are multiple paths (via references) to the same node, then we
> shouldn't end up with multiple copies of that node). Some care will also
> need to be taken to deal with cyclic structures, etc.. And some
> optimizations can probably be done to avoid copying immutable objects,
> since that would be a waste of time & memory.

Good idea.Detecting immutable seems easy. Doing a graph traversal is a
bit trickier.


More information about the Digitalmars-d mailing list