I'm back

[Timon Gehr]

On 11/14/2012 11:18 PM, Andrei Alexandrescu wrote:
> On 11/14/12 11:18 AM, Timon Gehr wrote:
>> On 11/14/2012 06:43 PM, Andrei Alexandrescu wrote:
>>> On 11/14/12 7:29 AM, H. S. Teoh wrote:
>>>> But since this isn't going to be fixed properly, then the only solution
>>>> left is to arbitrarily declare transient ranges as not ranges (even
>>>> though the concept of ranges itself has no such implication, and many
>>>> algorithms don't even need such assumptions), and move on. We will just
>>>> have to put up with an inferior implementation of std.algorithm and
>>>> duplicate code when one*does* need to work with transient ranges. It is
>>>> not a big loss anyway, since one can simply implement one's own library
>>>> to deal with this issue properly.
>>>
>>> What is your answer to my solution?
>>>
>>> transient elements == input range && not forward range && element type
>>> has mutable indirections.
>>>
>>> This is testable by any interested clients, covers a whole lot of
>>> ground, and has a good intuition behind it.
>>>
>>>
>>> Andrei
>>
>> That is a very imprecise approximation. I think it does not cover any
>> ground: The day eg. 'array' will require this kind of non-transient
>> element range is the day where I will write my own.
>
> What would be an example where array would have trouble with using this
> definition?
>
> Andrei

import std.array, std.range, std.algorithm, std.stdio, std.conv;

class C{
     int	x;
     this(int x){ this.x = x; }
     string toString(){ return "C("~to!string(x)~")"; }
}

void main(){
     auto a = iota(0,100).map!(a=>new C(a)).array;
     writeln(a);
}