swap using Concepts

延續從《HasSwap》到《Concepts vs. Type Traits (vs. Reflection)》的討論，我擔心的事情果然成真：後面一篇文章所提的 template overloading 會形成歧義（ambiguity）。以下使用 N2042 所述的語法和語意（也就是 ConceptGCC 所實作的 concept system），建議搭配該篇 paper 閱讀本篇（因為這篇是非常典型的跳躍式邏輯 XD）。

auto concept MemberSwappable<typename T> {
  void T::swap(T&);
};

上述宣告引進一個新的 concept MemberSwappable，此類型別必須擁有一個 member function swap，signature 如 concept declaration 所示。ConceptGCC 使用偏向 pseudo-signature 的 concept 表述方式，但應該只是為了實作方便，pseudo-signature vs. usage pattern 的討論應該還沒定案。auto 代表這個 concept 採用 implicit model，省略的話，欲匹配這個 concept 的型別必須用 concept_map 明確宣稱。

Standard library 已經預先定義了 Swappable concept。我們可以用 concept map template 表述「所有為 MemberSwappable 的型別 T 都為 Swappable」：

template <MemberSwappable T>  // for every MemberSwappable T
concept_map Swappable<T> {
  void swap(T& a, T& b) { a.swap(b); }
};

如上述程式碼所示，使用 concept map 時可以把 concept 所要求的語法（e.g., non-member swap）對映到實際型別的操作（e.g., member swap）。這很像 OOP 的 virtual functions，例如：

template <Swappable T>
void f(T& a, T& b) {
  swap(a, b);
}

若 T 單純是個 Swappable，那麼會喚起 Swappable 所指定的 non-member swap；但若 T 是個 MemberSwappable，則 Swappable 所指定的 non-member 呼叫語法（i.e.，介面）會被轉換為 MemberSwappable 所指定的 member 呼叫語法（i.e.，實作）：行為正與 virtual functions 類似。

故事還沒完。事實上，到此編譯器會抱怨 "ambiguous class template instantiation for 'concept std::Swappable<Test>' "，因為在 concept-enabled STL 中，std::swap 乃如此定義：

template <typename T>
  where Assignable<T> && CopyConstructible<T> {
inline void swap(T& a, T& b) {
  T tmp = a;
  a = b;
  b = tmp;
}

template <typename T>
  where Assignable<T> && CopyConstructible<T>
concept_map Swappable<T> { };

因為 STL 為所有「既為 Assignable 又為 CopyConstructible」的型別提供了 non-member swap，所以用 concept map template 宣稱「所有Assignable 且 CopyConstructible 的型別均為 Swappable」很合理。但這在定義 f、實施 concept-checking 而試圖（自動）檢驗 Test 是否為 Swappable 時，卻發生麻煩：編譯器不知道應該把 Test 歸類為 Assignable && CopyConstructible 還是 MemberSwappable（而不知道該喚起 std::swap 還是 Test::swap）！

我試著解釋目前我理解（猜測）的內幕：auto concepts 事實上是由編譯器暗自產出 concept maps，然後所有操作再根據 concept maps 進行（無論是由編譯器暗自產出的還是使用者明確宣告的）。兩個 concept maps 所指明的關係如下面這個集合圖所示：

而且左右側兩個子集所對應的實際操作不同，所以匹配時必須獨一無二地讓型別落在其中一個子集內。如果，例如，把 Test 的 copy ctor 放在 private 區段，使 T 不為 CopyConstructible，那麼對 f 的呼叫就會成功，喚起 Test::swap。但現在 Test 剛好位於兩個子集的交集內，無法判斷從通用介面呼叫時，要的是哪個子集所定義的操作。喔，這不正是惡名昭彰的鑽石型多重繼承的 compile-time version 嗎？！真是糟糕啊，感覺上沒有比較好的一般解決方案。

--
一篇文章還沒看完就忍不住了 XD。