title: Async/Await refactor approach
body: <p>When we look at the generated IL code we quickly realize that async mechanics is nice but not free.<br>
  How to approach the implementation of such a vampiric code ...<br>
  Example :<br></p>
  <p>Imagine that the following method (uninteresting i'm ok) is called almost everywhere in an app..</p>
  <pre><code>private Dictionary&lt;string,string&gt; _cache = new Dictionary&lt;string,string&gt;();
  public string FirstWord(string t)
  {
    if(!_cache.TryGetValue(t, out var r))
      cache[t] = r = t[0, t.IndexOf(' ')];
    return r;
  }
  </code></pre>
  <p>In time this method will become more expensive with a path as a parameter (it could have been a URL or other).<br>
  It should naturally evolve into async such as:</p>
  <pre><code>private Dictionary&lt;string,string&gt; _cache = new Dictionary&lt;string,string&gt;();
  public async Task&lt;string&gt; FirstWord(string path)
  {
    if(!_cache.TryGetValue(path, out var r))
    {
      var t= await Path.ReadAllTextAsync(path);
      cache[path] = r = t[0, t.IndexOf(' ')];
    }
    return r;
  }
  </code></pre>
  <p>As this method is used everywhere I am tempted to migrate all of my code in async<br>
  This transformation will also force me to do these kinds of things to manage overloads:</p>
  <pre><code>public async Task&lt;string&gt; FirstWord()
    =&gt; await FirstWord(&quot;Default&quot;);
  public async Task&lt;string&gt; FirstWord(string path)
  </code></pre>
  <p>The overload without parameters will have to implement an async / await logic to just call the other overload (IL add try / catch...) ...<br></p>
  <p>Should this caching be limited by using a GetAwaiter().GetResult() ...?<br>
  Do not do async knowing that this approach will require a general transformation can be more expensive?<br></p>
  <p>Your impressions? Your approach?<br></p>
  <p>Thanks for your feedback</p>