Transience of .front in input vs. forward ranges

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon Nov 5 22:56:42 PST 2012


On 11/6/12 7:48 AM, H. S. Teoh wrote:
> On Tue, Nov 06, 2012 at 05:49:44AM +0100, Tommi wrote:
>> On Tuesday, 6 November 2012 at 04:31:56 UTC, H. S. Teoh wrote:
>>> The problem is that you can't do this in generic code, because
>>> generic code by definition doesn't know how to copy an arbitrary
>>> type.
>>
>> I'm not familiar with that definition of generic code. But I do feel
>> that there's a pretty big problem with a language design if the
>> language doesn't provide a generic way to make a copy of a variable.
>> To be fair, e.g. C++ doesn't provide that either.
>
> OK I worded that poorly. All I meant was that currently, there is no
> generic way to make a copy of something. It could be construed to be a
> bug or a language deficiency, but that's how things are currently.
>
> One *could* introduce a new language construct for making a copy of
> something, of course, but that leads to all sorts of issues about
> implicit allocation, how to eliminate unnecessary implicit copying,
> etc.. It's not a simple problem, in spite of the simplicity of stating
> the problem.

Here's where user defined @tributes would help a lot. We'd then define 
@owned to mention that a class reference field inside an object must be 
duplicated upon copy:

class A { ... }

struct B
{
    @owned A payload;
    A another;
    ...
}

That way a generic clone() routine could be written.


Andrei


More information about the Digitalmars-d mailing list