如果要改進C語言，您最希望添加哪些語言特性，移除哪些語言特性？

01-13

伴隨著UNIX誕生並一起走向成功的C語言，經歷了40多年的發展，雖然依然保持著自己的生機與活力，牢牢地在計算機領域中佔據著一席之地。
但是隨著技術的不斷發展，新興的軟體需求，編程理論等催生了更加強大的語言的誕生，C++，Java，C#等以面向對象為基礎理論的語言大行其道，迅速在編程語言的鬥爭中勝出，贏得自己的一席之地，並不斷成長。另外，又有這如通Rust，Golang這樣的不僅希望能夠在敏捷開發的應用領域中大展其手，並且意圖在系統編程領域中也插一腳，意圖取代C。
C語言是一門設計的十分簡潔的語言，不具備現代編程語言的諸多特性，同時C語言自身也在不斷的發展，但是每一次C標準的變更，都會為C語言添加上不同的功能。但是由於C語言有著沉重的歷史負擔，使得C語言自身的發展和進化受到了很大的限制。
編譯原理是一門計算機的核心課程，也是計算機領域的一個核心研究領域，我想有許多的朋友都試圖實現一個編譯器/解釋器，而往往我們定義一個C語言的子集來實現。
那麼，在使用過程中，您覺得C語言的那些特性是十分優秀的，又有那些事令你十分討厭的，如果您想要在C語言中加入或者是改善他的語言特性，是異常，是重載，垃圾回收，自動內存管理，又或是其他么。

C 語言往上面（抽象）發展肯定是會被噴的，所以只能往下面（平台相關的）發展，比如_Atomic 這種玩意兒。

所以C語言多和彙編一級的東西多打通就好了，典型如有棧協程（無棧協程應該交給C++去搞），比如說支持標記一個地址的內容已經被no alias move了（類似於std::move，標識這塊空間已經不被使用了，編譯器可以在上面隨便放點臨時的東西啦，不用非得浪費堆棧，，很多結構體的部分成員被當作輸入參數來使用，其實往往在函數一開始之後，這些空間就可以隨便用了），，事情多的很，經常寫彙編的人清楚的很C語言可以優化和向下發展的空間非常巨大。

Packed struct / bitfield（現在的 struct / bitfield 都沒有標準化的、嚴格禁止添加 padding 的變體）

類似 Pascal 的 var 參數（C++ 的 reference）

至於重載嘛，其實用 Haskell 的那種 typeclass 更好一點，當然要引入這個肯定得加 HM 式的 parametric polymorphism 了

加入 namespace關鍵字、引用(）符號、 interface(介面) 關鍵字、import（包引入）關鍵字、

操作符重載。這就是完美語言。

不需要class面對對象、不需要模板、不需要異常處理、不需要垃圾回收、不需要多值返回。。。

相反，我希望C語言刪除特性，回歸「彙編的映射」這個地位

C99開始，C語言在語言層面增加了複數類型，VLA，_Atomic，_Thread_local，_Thread等一系列操作系統（運行時）機制，我覺得搞這些東西既無益與C語言的跨平台（畢竟寫C的多半都是system級別的應用），又憑空增加語言複雜度，不好

我想法跟 @孫明琦的差不多，c 語言回歸最初」彙編的映射「是最好的。一門語言能做好一件事就可以了，所謂的」優秀特性「就交給其他語言或者是語法糖吧。

一定要說的話，我希望 C 能提供兩個語言之外的特性 -- 官方欽定的包管理器和構建工具。作為一個極度依賴三方庫的語言，這兩項工具的缺位帶來了太多負面影響。

或許該出現個更像結構化彙編的 C 變體（不是改進）？

不少人像寫彙編一樣寫 C ，遲早遇到越界訪問、嚴格別名使用違規等 UB 。

另外標準 C 是不允許函數指針和對象指針互轉的，能轉的都是編譯器擴展。

如果出一些理論上對應彙編能正確就沒有 UB 的 C 變體，在某些領域（如二進位安全）可能會更靈活。

我要調用函數你去找就行了，聲明個毛

衛生宏

題主的原問題為《如果要改進C語言，您認為什麼特性最希望那些特性被加入到C語言中？》。

--- 原答案如下 ----

多返回值。

這樣可以大大減少使用傳入一個指針來獲取額外返回信息的做法。例如：

long int strtol(const char *nptr, char **endptr, int base);

使用多返回值寫成：

[long int, char *] strtol(const char *nptr, int base);

調用的語法可以設計為：

[value, endptr] = strtol(my_string, 10);

只對其中一個返回值感興趣時：

[value] = strtol(my_string, 10);
[, endptr] = strtol(my_string, 10);

放到變數初始化里：

[long value, char *endptr] = strtol(my_string, 10);

return 語句：

return [value, endptr];

ABI：前幾個簡單類型的返回值放到幾個寄存器；更多的返回值或複雜類型由調用者傳入地址，類似現在返回 struct 的方式。

Continuation，既足夠底層，體現出通用彙編應有的靈活性，同時也擁有了足以叫板一大波，比如函數式這種所謂具有高級抽象能力的，語言的特性。

Shared關鍵字（及語義），取代共享指針，簡單高效又徹底的告別內存管理難題。

有人提到多返回值，這的確也是一個比較通用的需求，但不一定是返回值，應該一併作為參數看待更加合理。類似swift那樣，要更通用靈活，便於優化，語法上也可以做到更加簡潔，方便元語言設計。

函數重載？？

我寫KotlinNative的時候才想起來C語言不能重載函數(?_?)這貨只打算支持C，不支持C++

摒棄申明和實現分離的設計，也就是只用c文件不用頭文件，加上export關鍵字，導出需要的類型和函數聲明，編譯階段生成基於llvm的位元組碼，鏈接階段再生產原生代碼，再加上包和名字空間的支持。

命名空間，取名字時不用寫一大串

模板，類型無關的代碼中取代宏或void*

函數參數默認值，重載就不要了，不然惹來一大堆問題

1. 以 0 結尾的字元串改成計數式的

2. 泛型（不要模板）

3. Trait

4. 圖靈完備的衛生宏

其他高級功能都無所謂了，無非就是代碼啰嗦點而已。

砍掉原有的宏，換上 Dlang 那套 static if 類的東西。

盡量減少隱式轉換。

將 icu4c 內置到標準庫。

將 glib 內置到標準庫。

引入 Dlang 的模板。

按照不可能三角原理，新特性、向下兼容、簡潔，三者最多只能選其二。想來想去，還是覺得不要新特性比較好。

謝邀

我覺得，c語言最缺的，就是編譯階段的流程式控制制，目前只能做到#if等條件判斷，利用模板可以做更多的事，但是，如果能像c語言自身的語法的話，那就可以在編譯階段動態生成代碼了。

或許對大多數人來說這是多餘的，但是深入使用後，會發現，編譯階段如果可以通過程序生成源碼的話，目前的很多奇怪的語法都會消失。

還有，編譯階段，針對類型的編程也是我一直想要的。

覺得C語言有幾個是很需要加入的：

【1】模塊。pascal在沒有類的時代就引入了模塊了，實際上表現也比c的頭文件形式好得多，現在幾乎所有語言都加入模塊了，除了那些已經不再繼續發展的「死語言」，所以不要再猶豫了。

【2】標準的錯誤處理模式。在C中到目前還沒有標準的錯誤處理模式，最傳統的共享一個全局的錯誤號，這種在多線程模式下容易混亂，採用返回值模式又喪失了函數返回值可以參與表達式的優勢，採用參數法則顯得很臃腫。還是喜歡異常的處理方法，不過如何在C中優雅實現需要斟酌。

【3】預編譯指令的替換，這個本質上是編譯期計算，所以乾脆和模塊一起引入一個專用的編譯語言結構算了。

加個運算符重載會比較好。

這樣的話，像字元串的strcat就可以直接用加號代替。

1. 類似golang interface的多態性

2. 模板