SelectMany<T, Unit> Task

Question

Hi,

Rx 2.0 Beta has overloads of SelectMany that accept Task<TResult> but none that accept Task.  I just noticed because I needed it now, but was surprised to find out that it doesn't exist.

public static IObservable<Unit> SelectMany<TSource>(this IObservable<TSource> source, Func<TSource, Task> selector)

and

public static IObservable<TResult> SelectMany<TSource, TResult>(this IObservable<TSource> source, Func<TSource, Task> collectionSelector, Func<TSource, TResult> resultSelector)

Thanks,
Dave

---

http://davesexton.com/blog

Answer 1

Hi,

Of course, ToObservable works just as well, so perhaps it's not a bid deal.  I just found it to be counter-intuitive that one kind is supported but not the other.

- Dave

---

http://davesexton.com/blog

Answer 2

Thanks for the feedback. It's unlikely we'll add those due to the large number of overloads that may need to be added to have a consistent story across Rx. What's the particular use case for SelectMany with a non-generic Task? It'd seem this leads to Func<Unit, ...> signatures, which would be abbreviated to drop the Unit parts, leading to overloads that are inconsistent in generic arity.

---

using (Microsoft.Sql.Cloud.DataProgrammability.Rx) { Signature.Emit("Bart De Smet"); }

Answer 3

Hi Bart,

Thanks, it's not a problem.  ToObservable is good enough.

Though I don't think that Unit would have to be dropped from the parameters (see example below).  I also didn't consider that changing the generic arity would prevent the compiler from binding to SelectMany when using query comprehension syntax, does it?  Is that your concern?

> What's the particular use case for SelectMany with a non-generic Task?

I've written a proof-of-concept TCP Qbservable provider (i.e., fully serializable expression trees, anonymous types, full duplex communication, etc.).  I'm targeting this weekend for release in a new branch of the Rxx project.  (Shameless plug ;)

The protocol class defines various async methods that return a non-generic Task.  The client-side method that is responsible for composing the query using these methods currently looks like this:

public IObservable<TResult> ExecuteClient<TResult>(Expression expression, object argument)
{
	return from _ in InitializeSinks().ToObservable()
					from __ in ClientSendAsync(expression, argument).ToObservable()
					from result in ClientReceive<TResult>()
					select result;
}

When I was writing this query, I tried adding the line that uses ClientSendAsync without calling ToObservable.  ClientSendAsync returns a non-generic Task.

So my expectation was that Unit wasn't removed from the function, because I'm targeting query comprehension syntax.

That's the only use-case I've got so far :)

Thanks,
Dave

---

http://davesexton.com/blog