C में पॉलीमॉर्फिक टाइप्स [pdf]
C भाषा में polymorphic types जोड़ने के एक प्रस्ताव ने, `_Type` और `_Var` जैसे नए constructs के माध्यम से, C के विकास की सीमा बनाम C++ या नई systems languages पर निर्भर रहने को लेकर लंबे समय से चली आ रही तनातनी को फिर से भड़का दिया है। समर्थकों का तर्क है कि type-safe generics, बेहतर arrays, और runtime type information safety, reuse, और interoperability को खास तौर पर embedded और aviation जैसे क्षेत्रों में बेहतर बनाएँगे, जहाँ C++ compilers उपलब्ध नहीं होते या भरोसेमंद नहीं होते। आलोचक कहते हैं कि design तात्कालिक और syntactically ugly लगता है, proven ideas को साफ़ तौर पर अपनाने के बजाय C में आधे-अधूरे बदलाव जोड़कर इसे “bloat” कर सकता है, और C को एक छोटे, predictable core language के रूप में उसकी अपील कमजोर कर सकता है।
C में पॉलीमॉर्फिक टाइप्स की समग्र प्रतिक्रिया
- कई लोगों को पॉलीमॉर्फिक टाइप्स वास्तव में उपयोगी लगते हैं, खासकर generic libraries और
void*पैटर्न के अधिक सुरक्षित विकल्पों के लिए। - इस प्रस्ताव को “brave” माना गया है, लेकिन साथ ही “patch-like” और C की मौजूदा type system पर अजीब तरह से चिपकाया हुआ भी, बजाय एक साफ़, first-class design के।
- कुछ लोगों को यह पसंद है कि इसका लक्ष्य C++-style templates से आगे जाकर अधिक शक्तिशाली polymorphic/dependent typing तक पहुँचना है, जिससे monomorphization और code bloat से बचा जा सके।
- अन्य लोग conditional semantic rules (“केवल कुछ contexts में मान्य”) की आलोचना करते हैं, क्योंकि यह C++ की जटिलता जैसा लगता है और code के बारे में reasoning को कठिन बनाता है।
C बनाम C++ और अन्य भाषाएँ
- एक बार-बार लौटने वाला विषय: generics और polymorphism के लिए “बस C++ इस्तेमाल करो” बनाम “C++ bloated और messy है।”
- कई लोगों का तर्क है कि C को C++ के सिर्फ “अच्छे हिस्से” एक सरल रूप में चुनने चाहिए; जबकि अन्य मानते हैं कि ऐसा नहीं हो रहा—नई features आधी-अधूरी लगती हैं और ज़रूरत से ज़्यादा अजीब हैं।
- कुछ लोग complexity और वास्तविक codebases में उन्नत C++ features के misuse का हवाला देते हुए C++ से वापस C पर आ गए हैं।
- चर्चा किए गए विकल्प: Rust (जो feature bloat की ओर बढ़ता माना जाता है), Ada (मज़बूत लेकिन बेचने में कठिन), Zig/Odin/D के साथ
-betterC, और C3 (जिसमेंany*और “no big ideas” की philosophy है)।
Type safety, arrays, और void*
- इस पर बहस कि क्या C++ स्वाभाविक रूप से C से अधिक type-safe है:
- C++ समर्थक template generics,
std::array, stronger pointer type checking, औरstatic_castका हवाला देते हैं। - C समर्थक कहते हैं कि आधुनिक C और सावधान शैली (decayed arrays नहीं, minimal casts, safety के लिए macros) से समान सुरक्षा हासिल की जा सकती है।
- C++ समर्थक template generics,
- Multi-dimensional arrays: कुछ लोग C के VLAs को C++ arrays से बेहतर मानते हैं; अन्य इन्हें security risk कहते हैं, जबकि जवाब में कहा जाता है कि stack protections इससे निपट लेते हैं।
void*-आधारित APIs (जैसेqsort, PAM, Wayland) को pain points के रूप में उद्धृत किया जाता है; type-safe generics को एक प्रमुख प्रेरणा माना जाता है।
Syntax, keywords, और aesthetics
_Type/_Var/_Genericकी aesthetics के प्रति कड़ा dislike; कई लोग नोट करते हैं कि C codebases में all-lowercase identifiers पसंद किए जाते हैं।- व्याख्या: leading-underscore-with-capital पहले से मौजूद code को तोड़ने से बचाने के लिए reserved है; बाद में lowercase aliases या true keywords आ सकते हैं (जैसे C23 में
_Bool→bool)। - चिंता कि कुछ keywords (जैसे
_Generic) को कभी nicer aliases नहीं मिले, जिससे adoption सीमित रही; ऐसी ही चिंता_Typeऔर_Varके लिए भी है।
Use cases और dynamic typing / FFI
- प्रस्तावित लाभों में शामिल हैं:
- Type-safe generic interfaces (जैसे
qsort-like functions)। - Language interoperability के लिए runtime पर types और function calls बनाना आसान होना, यदि
_Typeofinspectable runtime type descriptions दे सके।
- Type-safe generic interfaces (जैसे
- कुछ लोग पूछते हैं कि क्या ये ज़रूरतें C को जटिल बनाने को उचित ठहराती हैं, बजाय किसी अलग भाषा के चयन के; अन्य तर्क देते हैं कि कोई मौजूदा भाषा C की simplicity, portability, और control के संयोजन से मेल नहीं खाती।