C++26 कॉन्ट्रैक्ट्स: प्री-कंडीशन्स और पोस्ट-कंडीशन्स का परिचय

मूल लेख ↗ Hacker News चर्चा ↗

C++26 की नई Contracts सुविधा, जो function declarations में standardized preconditions और postconditions जोड़ती है, उत्साह और संदेह दोनों पैदा कर रही है। समर्थक इसे “code as documentation” को machine-checkable invariants में बदलने का तरीका मानते हैं, जो debugging, static analysis, optimization और यहाँ तक कि AI tooling में मदद कर सकता है, जबकि runtime पर optional भी रहता है। आलोचकों का कहना है कि semantics उलझे हुए हैं—खासकर input validation और checks को compile out किए जाने की स्थिति को लेकर—जिससे Contracts `assert` का एक भारी और अधिक भ्रमित करने वाला रूप लगते हैं, जो formal verification की उम्मीदों पर खरा न उतर सके।

कॉन्ट्रैक्ट्स और औपचारिक सत्यापन की भूमिका

  • कई लोग C++26 कॉन्ट्रैक्ट्स को Hoare triples (pre/post/invariants) को एन्कोड करने और ऐसे verification conditions बनाने के तरीके के रूप में देखते हैं, जिन्हें tools/solvers जाँच सकें।
  • अन्य ecosystems (Racket, SPARK/Ada, specialized C/C++ verifiers) के उदाहरण इस बात के प्रमाण के रूप में उद्धृत किए जाते हैं कि एक सीमित subset को statically prove किया जा सकता है, भले ही पूरा C++ कभी न हो सके।
  • कॉन्ट्रैक्ट्स “messy” functions को अलग करने में मदद कर सकते हैं: उनके आसपास की हर चीज़ को इस मान्यता पर prove करें कि pre/post लागू हैं, और जहाँ proof fail हो उसे स्थानीयकृत करें।

Runtime व्यवहार बनाम इनपुट वैलिडेशन

  • व्यापक सहमति: contracts “यह कभी नहीं होना चाहिए; अगर हुआ, तो यह bug है” के लिए हैं, न कि सामान्य user input validation के लिए।
  • कई लोग नोट करते हैं कि “input validation” और “assumptions” के बीच की सीमा धुंधली है और व्यवहार में इसका दुरुपयोग होने की संभावना है।
  • Contracts की तुलना asserts से की जाती है: भूमिका समान है, लेकिन standardized हैं, declaration पर visible हैं, और उनके multiple evaluation modes हैं (ignore, observe, checking)।
  • आलोचना “ghost code” मॉडल पर केंद्रित है: आपको मानना पड़ता है कि checks छोड़े जा सकते हैं, इसलिए safety-critical व्यवहार के लिए उन पर भरोसा नहीं किया जा सकता।

Optimisation और Performance

  • कुछ लोग आशा करते हैं कि compilers optimization के लिए contracts को assume की तरह उपयोग करेंगे या redundant checks हटाएँगे; अन्य कहते हैं कि यह primary design goal नहीं है।
  • निराशा यह है कि वर्तमान implementations में, “ignore” mode (कोई runtime checks नहीं) भी optimization को निर्देशित करता हुआ नहीं दिखता।
  • Embedded और high-performance developers को workstation पर checks सक्षम करके target builds पर उन्हें disable करने की सुविधा पसंद है।

Placement, Headers, और Modules

  • इस पर बहस है कि contracts कहाँ रखे जाएँ: headers उन्हें documentation के रूप में expose करते हैं, लेकिन भारी includes को मजबूर कर सकते हैं; .cpp files यह टालती हैं लेकिन visibility खो देती हैं।
  • Standard मांग करता है कि first declaration में contracts हों, जिससे उपयोग headers की ओर धकेला जाता है; कुछ लोग तर्क देते हैं कि modules compile-time blowups को कम करेंगे।
  • सुझाया गया pattern: header contracts को सरल रखें या उन्हें elsewhere defined helper functions को delegate करें।

Language Complexity और तुलनाएँ

  • कुछ लोग C++ को पहले से ही बहुत बड़ा मानते हैं और contracts को मामूली लाभ के लिए अतिरिक्त complexity समझते हैं; अन्य कहते हैं कि यह बस लंबे समय से उपयोग किए जा रहे एक pattern को formalize करता है।
  • Eiffel, D, Clojure, Racket, Rust, Go के साथ तुलना की गई: कई अन्य languages में contracts या pre/post सुविधाएँ हैं, लेकिन वास्तविक दुनिया की उपयोगिता को लेकर अनुभव मिश्रित हैं।

उपयोगिता, सुरक्षा, और टूलिंग

  • समर्थक IDEs, static analyzers, AI agents, और सटीक “executable documentation” के रूप में लाभों पर ज़ोर देते हैं।
  • संशयवादी तर्क देते हैं कि contracts “बस अधिक fancy asserts” हैं, इनके चलने की गारंटी नहीं दी जा सकती, और कुछ patterns में ये plain assert से भी कम सुरक्षित हो सकते हैं।
  • कुल मिलाकर: tooling और verification potential के प्रति सावधानीपूर्ण आशावाद, लेकिन व्यावहारिक रोज़मर्रा के लाभ और design trade-offs को लेकर पर्याप्त संदेह।