如何評價C++17中的新特性fold expression？

fold expression - cppreference.com

---

通用性太差了，希望刪除，按照老套路，在STL裡面加個模板函數就行了，犯不著做一個語法。

(1 * ... * xs)


v.s.

fold&(1, xs...) 或 fold(1, mul(), xs...)


並沒有覺得有什麼區別。一定要說的話，不如簡化一下lambda表達式的語法，把[](auto x, auto y){return x*y;}改成(x,y)=&>x*y

---

太垃圾了，只支持那麼幾個運算符，不支持自定義函數，想用還得用 wrapper 運算符重載什麼的玩意（Fold expressions with arbitrary callable?）。

另外我懷疑這玩意就是 C++ 宏太弱了，Rust 什麼的直接用宏就可以做

C++ 老是走這種路，因為沒有更通用的設施所以提供一些奇怪的功能。

---

C++標準委員會，只需引入一個別的腳本語言， 放預處理後編譯期前去解釋執行，就可以簡單解決這些各種問題（宏的功能太弱，但是你叫++啊，怎麼可以一輩子都被C的那點功能約束住呢，好好增強一下預處理功能吧，比加強模版強多了）。

---

把param pack看作一個列表，fold expr，顧名思義就是把這個列表給fold了

可惜用來fold的操作只能是運算符，局限性比較大，為什麼我這麼說呢，很多人會拿用fold expr來給tuple重寫operator&<&<來說明foldexpr的作用，可是你會發現，你甚至沒法在兩次輸出之間加上空格

我覺得fold expr能給我平時寫東西帶來方便的一點就是，你可以用逗號直接原地進行包擴展了。從前還得寫個swallow函數，還沒法接受void返回值

---

不用 fold expression

std::conjunction&< std::conjunction&...&>,
std::disjunction&&>...&>
&>::value


用 fold expression

(std::is_constructible_v& ...)
(!std::is_convertible_v& || ...)


不過功能還是有點不同的（前者可以避免多餘的 instantiation）

不過如果是在concepts的語境里，那麼fold expression也能避免instantiation（嘛，理論上），這時候

requires (std::is_constructible_v& ...)
(!std::is_convertible_v& || ...)


甚至比

std::enable_if_t&< std::conjunction&< std::conjunction&...&>,
std::disjunction&&>...&>
&>::value
&>


功能更強，並且fold expression好看多了

---

不知道為啥這麼多人反對。。。雖然。。。有些複雜不直觀。。。而且功能不強大，還完全可以通過其他方式代替，同時其他方式的實現還可以完成更多的功能。

但是至少這種方法寫起來稍微。。。短那麼一些。。。

---

十分醜陋。

為特定寫法專門創造規則，真無聊。你如何去讀懂fold expression中的...的含義？只能靠「這種用法是fold expression！所以意思就是這樣這樣。。。」，而非「...這個變長參數就是這樣拆開來的啦，遵循一個普適的規則。。」

這樣一來，...這個token的含義完全不明了。

以前我就很討厭...這種嚴重降低代碼可讀性的token，更嚴重的是...拆起來還特別麻煩。有這閒情逸緻不如把變長參數這種辣雞東西取消了，或是想出一些更加輕巧的用法。

為auto的腦補能力的加強點贊！

---

[[ so::young ]]
[[ so::good ]]
[[ maybe_unused ]]


---

C++這走向還不如Java（逃

---

推薦閱讀：