On Friday, 28 March 2014 at 22:12:02 UTC, H. S. Teoh wrote:
On Fri, Mar 28, 2014 at 10:44:11PM +0100, Artur Skawina wrote:
eg
auto f(A...)(A args) {
...
return cartesianProduct(x, y)
.joiner
.filter!(a=>somecondition?true:somefilter(a));
}
[...]
It's not that simple, though. I guess I gave a bad example. In
the
actual code, someCondition decides whether or not a cartesian
product is
even used. So the return range needs to somehow switch between a
cartesianProduct filtered by some filters, vs. an alternative
algorithm
filtered by some other filters.
T
That would have been my solution too (though maybe using a
delegate, to not re-evaluate "someconditon" per-element).
If both ranges are completely incompatible, then I'd either:
- array them into submission until they reach a single type.
- return both types, but have only 1 usable (eg, a tuple(type1,
type2, index)), and let the caller worry about it.
Or alternativelly, do it pass by ref style:
alias Result1 = /+Define complicated alias1 here+/
alias Result2 = /+Define complicated alias2 here+/
size_t f(A...)(ref Result1 res1, ref Result2 res2, A args) {
...
if (someCondition)
{
res1 = cartesianProduct(x, y)
.joiner;
return 0;
}
else
{
res2 cartesianProduct(x, y)
.joiner
.filter!someFilter;
return 1;
}
}
I think this has the "advantage" of delegating the choice of how
to merge the results: Take a single fork? Use an algebraic?
Caller decides.
