他の人が行ったように、これをAsyncチームに指摘しました。現在、契約と非同期は（ほぼ）相互排他的です。だから、マイクロソフトの少なくとも一部の人は、この問題を認識しているが、私は彼らがそれについて何をやろうとしているのか分からない。
同期メソッドのラッパーとして非同期メソッドを記述することはお勧めしません。実際、私は逆の傾向があります。
前提条件が働くことができます。私は最近それを試していない。前提条件を含む非同期メソッドの周りに小さなラッパーが必要な場合があります。
事後条件はかなり壊れています。
アサーションと仮定は正常に動作しますが、事後条件が壊れているため、静的チェッカーは実際には制限されています。
不変条件は、変更可能な状態がちょうど途切れることの多い非同期世界では、それほど意味を持たない。 （非同期で、OOPから機能的なスタイルに向かって優しくあなたを押しのけます）。
うまくいけばVS vNextで、契約は非同期対応のポストコンディションで更新されます。これにより、静的チェッカーが非同期メソッドのアサーションでよりうまく動作できるようになります。
その間に、あなたは仮定を書くことによって偽装 - 事後条件を持つことができます：
// Synchronous version for comparison.
public static string Reverse(string s)
{
Contract.Requires(s != null);
Contract.Ensures(Contract.Result() != null);
return ...;
}
// First wrapper takes care of preconditions (synchronously).
public static Task ReverseAsync(string s)
{
Contract.Requires(s != null);
return ReverseWithPostconditionAsync(s);
}
// Second wrapper takes care of postconditions (asynchronously).
private static async Task ReverseWithPostconditionAsync(string s)
{
var result = await ReverseImplAsync(s);
//Check our "postcondition"
Contract.Assume(result != null);
return result;
}
private static async Task ReverseImplAsync(string s)
{
return ...;
}
インタフェースや基底クラスの非同期メンバの事後条件を指定するなど、コード契約の用途はまったくできません。
個人的には、非同期コードで契約を完全に回避し、Microsoftが数カ月後に修正することを期待しています。