On Sun, May 30, 2010 at 15:48, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:
>
>> Will the definition of a forward range change to incorporate save, or do
>> you intend to distinguish ranges that can do
>>
>> R r2 = r1;
>> and those that have:
>> auto r2 = r1.save;
>> ?
>> Until now, they were one and the same to me.
>>
>
>
> Yah. Essentially R r2 = r1; is not a guarantee that r2 is independent from
> r1. (The obvious case: R is a class or interface type.) You'll need to call
> R r2 = r1.save; to make sure that now you have two independently-moving
> ranges. So yes, save must be a member of all forward ranges. isForwardRange
> will yield false if it doesn't find save.
>
OK, understood.
>>
> An input range can be initialized from another input range, with the
> mention that it doesn't leave the original range independent from the copy.
> So Map works as it is.
>
OK, so map(intputRange) could be affected after its creation by any
modification to inputRange, that's coherent. I don't think I was ever
confronted to this situation. I tend to discard ranges as I compose them.
> Lazy and input ranges are not incompatible.
>
I see that now. I really thought that a = b was a no-no for input ranges.
>
>> // at module scope
>> void swapFront(Range)(Range r1, Range r2)
>> {
>> static if (is(typeof(&(r1.front)) == ElementType!(Range)*)) {
>> swap(r1.front, r2.front);
>> } else {
>> static assert(is(typeof(&(r1.swapFront)), "Cannot swap
>> ranges");
>> r1.swapFront(r2);
>> }
>> }
>>
>>
>> OK. I really like this possibility to test for members and activate them
>> when possible. Maybe it could be abstracted away into a Select-like
>> template?
>>
>
> More detail please.
>
It's just that my code is full of these static ifs. They are clear but I'd
like two things:
IfPossible!(someCode); // static if (is( typeof())) or
__traits(compiles, someCode), then someCode. It's becoming a chore to
repeat twice the same line.
and:
ConditionalCode!(cond1, code1, // static if cond1 then code1
cond2, code2, // else static if
cond2 then code2
...
optionalDefaultCode);
But I have no solution except by using q{} strings... Maybe with lazy
void()?
>
> OK. So it's really sameFront and not equalFront or somesuch.
>>
>
>
> Yah. A previous attempt at naming was sameHead but I don't want to add too
> many notions.
>
Out of curiosity, what algorithm did you have in mind?
> I was thinking of frustrating obstacles like:
>>
>> auto m = map!"a*a"([0,1,2,3]);
>> auto c = cycle(m); // won't compile, m.front is not an lvalue, whereas
>> c.front asks for one.
>>
>> Putting auto ref front() {...} in Cycle does not change anything. Too bad.
>>
>
>
> That's a bug in the compiler.
>
I'll see if I can obtain a simple example and put it in bugzilla, then.
