title: Should we use ConfigureAwait(false) in libraries that call async callbacks?
body: <p>There are lots of guidelines for when to use <code>ConfigureAwait(false)</code>, when using await/async in C#.</p>
  
  <p>It seems the general recommendation is to use <code>ConfigureAwait(false)</code> in library code, as it rarely depends on the synchronization context.</p>
  
  <p>However, assume we are writing some very generic utility code, which takes a function as input. A simple example could be the following (incomplete) functional combinators, to make simple task-based operations easier:</p>
  
  <p>Map:</p>
  
  <pre><code>public static async Task&lt;TResult&gt; Map&lt;T, TResult&gt;(this Task&lt;T&gt; task, Func&lt;T, TResult&gt; mapping)
  {
      return mapping(await task);
  }
  </code></pre>
  
  <p>FlatMap:</p>
  
  <pre><code>public static async Task&lt;TResult&gt; FlatMap&lt;T, TResult&gt;(this Task&lt;T&gt; task, Func&lt;T, Task&lt;TResult&gt;&gt; mapping)
  {
      return await mapping(await task);
  }
  </code></pre>
  
  <p>The question is, should we use <code>ConfigureAwait(false)</code> in this case? I am unsure how the context capture works wrt. closures.</p>
  
  <p>On one hand, if the combinators are used in a functional way, the synchronization context should not be necessary. On the other hand, people might misuse the API, and do context dependent stuff in the provided functions.</p>
  
  <p>One option would be to have separate methods for each scenario (<code>Map</code> and <code>MapWithContextCapture</code> or something), but it feels ugly.</p>
  
  <p>Another option might be to add the option to map/flatmap from and into a <code>ConfiguredTaskAwaitable&lt;T&gt;</code>, but as awaitables don't have to implement an interface this would result in a lot of redundant code, and in my opinion be even worse.</p>
  
  <p>Is there a good way to switch the responsibility to the caller, such that the implemented library doesn't need to make any assumptions on whether or not the context is needed in the provided mapping-functions? </p>
  
  <p>Or is it simply a fact, that async methods don't compose too well, without various assumptions?</p>
  
  <h3>EDIT</h3>
  
  <p>Just to clarify a few things:</p>
  
  <ol>
  <li>The problem <em>does</em> exist. When you execute the "callback" inside the utility function, the addition of <code>ConfigureAwait(false)</code> will result in a null sync. context.</li>
  <li>The main question is how we should tackle the situation. Should we ignore the fact that someone might want to use the sync. context, or is there a good way to shift the responsibility out to the caller, apart from adding some overload, flag or the like?</li>
  </ol>
  
  <p>As a few answers mention, it would be possible to add a bool-flag to the method, but as I see it, this is not too pretty either, as it will have to be propagated all the way through the API's (as there are more "utility" functions, depending on the ones shown above).</p>