Does awaiting a feed in None state should throw an exception?

[dr1rrb]

Currently, when we await a Feed<T> in None state, the return value is default(T?) (i.e. await State.Empty<int>(this) == null).

In order to avoid confusion between None and Some(null) we added a type constraint T : notnull. This means that you cannot await a Feed<int?> which might be confusing. To await a Feed<T?> you need to do await Feed<T?>.Option().

A solution could be to change the behavior (breaking change at runtime) to instead throw an exception if None. We would then be able to remove the type constraint on the GetAwaiter.

As usually when we await a Feed<T> (imperative code) we expect it to not be none, it could be simpler. And if user expects the feed to be none, he would then await Feed<T>.Option() to support it.

Case	Current	Proposed
When using nullable type	await Feed<T?>.Option()	await Feed<T?>
When expecting a None (no matter type of T)	await Feed<T>	await Feed<T>.Option()

Note:
Awaiter also have support for the 2 others "main axes"

• Loading: Awaiter will wait for the first non-transient value
• Error: If there is an error, the exception is being re-thrown by awaiter.

[carldebilly]

I totally support adding settings to the awaitable structure to configure what you're waiting for. It's an elegant and powerful pattern.

To prevent breaking change, you can still throw an exception if nothing is configured, since it makes no sense if you don't know what you're waiting for.