Choice ranges?

[monarch_dodra]

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.