Transience of .front in input vs. forward ranges

[Timon Gehr]

On 11/06/2012 07:56 AM, Andrei Alexandrescu wrote:
> 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

That is actually the first thing that I will use the new attribute 
system for.