More range woes: composed ranges are unsafe to return from functions

Timon Gehr timon.gehr at gmx.ch
Tue Oct 16 17:13:41 PDT 2012


On 10/17/2012 02:09 AM, H. S. Teoh wrote:
> On Wed, Oct 17, 2012 at 01:09:09AM +0200, Timon Gehr wrote:
> [...]
>> The following code is free of allocations if the compiler
>> implementation is correct:
>>
>> auto cprod(R1,R2)(R1 A, R2 B) {
>>      return zip(sequence!"n"(cast(size_t)0), A.save, B.save,
>> repeat(A), repeat(B))
>>          .map!(function(a) => chain(
>>                zip(repeat(a[1]), take(a[4].save,a[0])),
>>                zip(take(a[3].save,a[0]+1), repeat(a[2]))
>>          )).joiner;
>> }
>>
>> It also works around the issue. (note that I got rid of some UFCS
>> calls. The reason is that we don't know whether R1 and/or R2 actually
>> have a member named 'take' or 'repeat' that would hijack the function
>> we want to call.)
> [...]
>
> Hmph. I seem to be running into one compiler bug after another. Using
> the above code, which solves the initial problem, I get into another
> problem:
>
> 	void main() {
> 		auto A = sequence!"2*n"(0);
> 		auto B = sequence!"2*n+1"(0);
> 		auto AB = cprod(A,B);
>
> 		auto C = sequence!"100+n"(0);
> 		auto D = sequence!"200+n"(0);
> 		auto CD = cprod(C,D);
> 	}
>
> DMD gives this bizarre error:
>
> Error: function test3.cprod!(Sequence!("2*n",Tuple!(int)),Sequence!("2*n+1",Tuple!(int))).cprod.map!(__funcliteral2).map!(Zip!(Sequence!("n",Tuple!(uint)),Sequence!("100+n",Tuple!(int)),Sequence!("200+n",Tuple!(int)),Repeat!(Sequence!("100+n",Tuple!(int))),Repeat!(Sequence!("200+n",Tuple!(int))))).map is a nested function and cannot be accessed from test3.cprod!(Sequence!("100+n",Tuple!(int)),Sequence!("200+n",Tuple!(int))).cprod
>
> Commenting out either the first three lines (A, B, AB) or the second
> three lines (C, D, CD) makes the problem go away.
>
> Looking more carefully at the error message, it appears that dmd is for
> some strange reason trying to reuse the first instance of cprod when
> compiling cprod(C,D). This is totally wrong, since they should be
> completely separate instantiations. Why this is so, I've no idea. :-(
>
>
> T
>

Looks like http://d.puremagic.com/issues/show_bug.cgi?id=8542
But your test case is somewhat simpler, so it might be useful to add it 
there.





More information about the Digitalmars-d mailing list