I posted a question on stackoverflow about the cartesian product
of immutable ranges :
http://stackoverflow.com/questions/21368501/cartesian-product-of-immutable-ranges
There are a lot of various thing I don't understand.
This code compiles and run :
import std.stdio;
import std.
On Sunday, 26 January 2014 at 21:49:37 UTC, matovitch wrote:
void main() {
immutable int[] B = [ 1, 2, 3 ];
immutable int[] C = [ 4, 5, 6 ];
auto BC = zip(B, C);
writeln(BC);
}
Here B and C aren't inputRange thought acording to the template
constraint of zip there should be. H
On Sunday, 26 January 2014 at 22:19:47 UTC, Stanislav Blinov
wrote:
On Sunday, 26 January 2014 at 21:49:37 UTC, matovitch wrote:
void main() {
immutable int[] B = [ 1, 2, 3 ];
immutable int[] C = [ 4, 5, 6 ];
auto BC = zip(B, C);
writeln(BC);
}
Here B and C aren't inputRange thoug
On Sunday, 26 January 2014 at 22:32:32 UTC, matovitch wrote:
You mean that two input ranges are created from the immutable
arrays when I call the function ?
Zip doesn't compiles while zip compile. :/
`Zip` must be explicitly instantiated, which allows you to
attempt to instantiate it with he
On Sunday, 26 January 2014 at 22:52:56 UTC, Jakob Ovrum wrote:
On Sunday, 26 January 2014 at 22:32:32 UTC, matovitch wrote:
You mean that two input ranges are created from the immutable
arrays when I call the function ?
Zip doesn't compiles while zip compile. :/
`Zip` must be explicitly inst
On Sunday, 26 January 2014 at 22:19:47 UTC, Stanislav Blinov
wrote:
On Sunday, 26 January 2014 at 21:49:37 UTC, matovitch wrote:
Short answer: with std.algorithm - you can't. Because internally
it (Zip, actually) performs assignments, and you can't assign to
immutable(T).
Why?
Here is the pro
You might want to consider submitting a bug report on account of
cartesianProduct() not being able to deal with ranges of
immutable elements. The worst that can happen is that you'd get a
real expert's explanation on why it's not a bug. But who knows,
perhaps it is :)
