Transience of .front in input vs. forward ranges

[Andrei Alexandrescu]

On 11/6/12 3:50 PM, deadalnix wrote:
> Le 06/11/2012 07:56, Andrei Alexandrescu a écrit :
>> 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.
>>
>
> You mentioned me once that AOP was useless in D.

What's the connection?

Andrei