C++26 در خط پایان بر سر اختلاف قراردادها دچار لغزش شد

نسخه بعدی زبان برنامه نویسی C++ ممکن است در آخرین لحظه به دلیل اختلاف بر سر ویژگی افزایش امنیت Contracts به تعویق بیفتد.

قراردادها باعث ایجاد شکاف عمیق در نگهبانان فنی ++C شده است. یک گروه از Bjarne Stroustrup خالق C++ حمایت می کند، که با این فناوری در شکل کنونی اش مخالف است زیرا به دلیل اجرای عجولانه آن مخالف است. اما برخی دیگر مشتاق دیدن اجرای قراردادها هستند، حتی با این استدلال که مخالفان فناوری در حال مسموم کردن خود فرآیند توسعه C++ هستند.

این اختلاف درست قبل از رای گیری برای تصویب نسخه جدید زبان جوشید.

در اکتبر، پیش‌نویس استاندارد بین‌المللی (DIS) C++26 با رای ISO خود شکست خورد - مرحله بعدی تا آخرین مرحله در فرآیند تأیید سازمان بین‌المللی استاندارد که طی آن جزئیات فنی یک استاندارد به طور رسمی توسط مجموعه‌ای از نهادهای استاندارد ملی تأیید می‌شود.

در این رای گیری 13 رای موافق، 9 رای مخالف و 12 رای ممتنع به صندوق انداخته شد که به شرط ISO مبنی بر داشتن بیش از 25 درصد رای منفی نرسید. قراردادها نقطه گیر اصلی برای کسانی بود که رای منفی دادند.

اختلاف قراردادها

قراردادها به توسعه دهندگان این امکان را می دهند که پیش شرط ها و شرایط پس از آن را به کد اضافه کنند، همچنین اظهاراتی که بررسی می کنند آیا شرایط مشخص شده برقرار است یا خیر. چنین بررسی هایی می تواند به کشف خطاهای برنامه نویسی کمک کند که در غیر این صورت ممکن است منجر به رفتار نامشخص شود.

طراحی با قرارداد مدتهاست که ویژگی زبانهایی مانند آدا و ایفل بوده است.

توسعه‌دهندگان پیشنهاد کرده‌اند که قراردادها را حداقل برای یک دهه به C++ اضافه کنند، پس از آن که به‌دلیل نگرانی‌ها در مورد پیش‌فرض‌های خطرناک، ناگهان از C++20 خارج شدند.

اما Stroustrup پیشنهاد تجدید نظر شده (P2900) را برشته کرد که آن را به C++26 تبدیل کرد.

استراستروپ و همکارانش در مقاله‌ای در آگوست گذشته نوشتند: «قراردادها و تمدیدهای P2900 با هدف تغییر ماهیت ++C و تهدیدی وجودی برای C++ هستند و پیچیدگی و نفخ را اضافه می‌کنند». آنها خاطرنشان کردند که پیاده سازی نامرتب، قدیمی است، به اندازه کافی آزمایش نشده است و می تواند به طور موثرتری به عنوان یک کتابخانه پیاده سازی شود.

همه موافق نیستند. آندریاس فرتیگ، یکی از اعضای کمیته استانداردسازی C++، احساس می‌کند که انتقادات قبلا بررسی شده‌اند و وتو کردن این پیشنهاد در اواخر فرآیند انتشار C++ به خود C++ آسیب می‌زند.

فرتیگ در یک پست وبلاگی نوشت: "این موضوع سال ها کار شده است و چندین بار اکثریت رای را به شکل فعلی خود دریافت کرده است. با رای "نه"، یک سیستم مستقر که اساسا مبتنی بر اعتماد و همکاری محترمانه است، متزلزل شده است."

البته فیل در اتاق انتقاد دائمی است از اینکه چقدر آسان است برای توسعه دهندگان به طور تصادفی حفره های امنیتی در C++ ایجاد کنند که منجر به بیش از چند پروژه برای پذیرش Rust می شود. همانطور که استروستروپ اشاره می‌کند، افزودن کنترل‌ها ممکن است ویژگی اصلی C++ را که یک زبان پرسرعت است، مختل کند.

بازنده های دردناک

فرتیگ استروستروپ و شرکت را به بازنده شدید متهم کرد.

او نوشت: "هر استاندارد ISO به سادگی مجموعه ای از مصالحه است. همه گاهی می بازند و همه گاهی برنده می شوند." اما در این مورد، "طرف های بازنده از پذیرش ضرر خود امتناع کردند. سوالی که در درجه اول چگونگی حرکت رو به جلو را تعیین می کند این است که آیا گروه می تواند اعتماد را بازسازی کند."

برخلاف Fertig، هری بات، مدیر عامل C++ Alliance – که از کامپایلر EDG C++ منبع باز نگهداری می‌کند – بحث قراردادها را مخل خود C++ نمی‌داند.

او از طریق ایمیل به The Register نوشت: «پیش‌نویسی که بازگردانده می‌شود یک شکست در فرآیند نیست، بلکه فرآیند مطابق با هدف کار می‌کند. "این بدان معنا نیست که روند نمی تواند بهبود یابد. هدف باید آموختن از این موضوع و تقویت فرآیند باشد تا C++ بتواند به گونه ای که توسعه دهندگان می توانند به آن تکیه کنند به تکامل خود ادامه دهد."

الان به کجا

با شکست رای گیری در این مرحله از فرآیند استانداردسازی - که در تاریخ C++ نادر است - این زبان در خطر از دست دادن تاریخ ارسال مورد انتظار خود در سال جاری است. این نتیجه ممکن است همه را مجبور کند که به نسخه جدید به جای C++26 به عنوان "C++27" اشاره کنند. (این فقط نام غیر رسمی است؛ نام رسمی این هشتمین نسخه از زبان، اگر سال آینده منتشر شود، «ISO/IEC 14882:2027» خواهد بود.)

گروه کاری ISO C++ WG21 هفته آینده در Búzios، برزیل، برای فینال confronto تشکیل جلسه می دهد.

بر اساس یک پست وبلاگ از Thibault Ricord-Marchal، مشاور مهندسی نرم افزار در شرکت مشاوره Margo مستقر در پاریس، این گروه با تعدادی از انتخاب ها روبرو است.

آنها می توانند قراردادها را از مشخصات جدا کنند تا بقیه C++26 بتوانند ارسال شوند. هر چند این کار کثیف خواهد بود. دکمه واگرد باید در بسیاری از سخت شدن های کتابخانه ای که قبلا با استفاده از Contracts انجام شده است، شکسته شود.

گزینه دیگر انتقال قراردادها به یک مشخصات فنی جداگانه است، جایی که کار می تواند برای اصلاح فناوری ادامه یابد.

یا می توانند یک بازبینی جزئی انجام دهند، دوباره رای دهند و امیدوار باشند که هوای مطبوع برزیل همه را خنک کند