دولة

نحن نعمل بجد على تطبيق Go 1.13 ، الذي آمل أن يتم إطلاقه في أوائل أغسطس من هذا العام. هذا هو الإصدار الأول الذي سيتضمن تغييرات على وجه التحديد في اللغة (وليس فقط تغييرات طفيفة على المواصفات) بعد وقف طويل لأية تغييرات من هذا القبيل.

للوصول إلى هذه التغييرات في اللغة ، بدأنا بعدة مقترحات قابلة للتطبيق ، تم اختيارها من قائمة أكبر بكثير من عروض Go 2 ، وفقًا لعملية تقييم الاقتراح الجديدة الموضحة في المنشور " Go 2 ، لقد جئنا إلى هنا !". لقد أردنا أن يلعب الاختيار الأولي للمقترحات من جانبنا دورًا صغيرًا نسبيًا ، وأغلبه لا يسبب الجدل ، بحيث مع احتمال كبير أنهم سيخوضون العملية برمتها. يجب أن تكون التغييرات المقترحة متوافقة مع الإصدارات السابقة من أجل كسر أقل قدر ممكن ، لأن الوحدات (التي ستسمح لك في المستقبل بتحديد إصدار اللغة لوحدة نمطية معينة) لم تكن بعد وضع الإنشاء الافتراضي. باختصار ، كانت المرحلة الأولية الحالية للتغييرات تهدف إلى الانطلاق مرة أخرى واكتساب الخبرة بدلاً من حل المشكلات الكبيرة.

تم اختصار وتوسيع قائمة جملنا الأولية - Unicode في الشكل العام في المعرفات ، والحروف الصحيحة ثنائية ، ومحددات القيم الحرفية الرقمية ، وتغييرات البتات بواسطة عدد صحيح موقّع . لم ينجح الاقتراح الخاص بـ Unicode بشكل عام في المعرفات في الحد ، لأننا لم نتمكن من إعداد مستند تصميم في الوقت المناسب. تم توسيع عرض اقتراح القيم الثنائية الصحيحة بشكل كبير وأدى إلى مراجعة وتحديث شاملين لصيغة حرف العددية Go. أضفنا أيضًا مسودة اقتراح التحقق من الخطأ في Go 2 ، والتي تم قبولها جزئيًا.

بالنظر إلى هذه التغييرات الأولية على Go 1.13 ، فقد حان الوقت للتفكير في مستقبل Go 1.14 وتحديد ما نريد تغييره بعد ذلك.

اقتراحات للذهاب 1.14

الأهداف التي حددناها لـ Go اليوم هي نفسها في 2007: جعل تطوير البرامج قابلاً للتطوير . تتمثل العوائق الرئيسية الثلاثة التي تحول دون تحسين قابلية الوصول لـ Go في عدم وجود نظام لإدارة الحزم والإصدارات ، ودعم نظام معالجة الأخطاء بشكل أفضل ، والأدوية الجنيسة.

مع تحسين نظام Go module ، يتم حل مشكلة إدارة الحزم والإصدارات. لا تزال تحسين التعامل مع الأخطاء والعقاقير الوراثية. لقد عملنا على كلا الإصدارين وقدمنا مسودة مستندات التصميم في GopherCon العام الماضي في دنفر. منذ ذلك الحين ، قمنا بتحسينها تدريجيا. فيما يتعلق بمعالجة الأخطاء ، نشرنا اقتراحًا منقحًا ومبسَّطًا بشكل كبير (انظر أدناه). أما بالنسبة للأدوية ، فنحن نعمل على ذلك ، حيث سيلقي إيان لانس لانسور "Generics in Go" خطابًا حول هذا الموضوع في GopherCon في سان دييغو هذا العام ، لكننا لم نصل بعد إلى المرحلة حيث يمكننا تقديم اقتراح محدد.

نريد أيضًا الاستمرار في تحسين اللغة نفسها تدريجيًا. بالنسبة لـ Go 1.14 ، اخترنا العروض التالية:

# 32437 . وظيفة التحقق من الخطأ المضمنة هي "try" ( مستند التصميم ).

هذا هو اقتراحنا لتحسين معالجة الأخطاء. على الرغم من أن ملحق اللغة المتوافق مع الإصدارات السابق صغير ، إلا أننا نتوقع تأثيرًا كبيرًا على رمز معالجة الأخطاء. تسبب هذا الاقتراح بالفعل في عدد كبير من التعليقات ، وهذا ليس من السهل متابعته. نوصي بالبدء بالتعليق الأول للحصول على وصف موجز ، ثم قراءة مستند التصميم التفصيلي. يحتوي التعليق الأول على زوجين من الروابط إلى ملخص المراجعات. يرجى اتباع إرشادات التعليقات (انظر قسم "الخطوات التالية") قبل الرد.

# 6977 . السماح بتضمين الواجهات المتداخلة ( مستند التصميم ).

هذا اقتراح قديم متوافق مع الإصدارات السابقة لجعل واجهات التضمين أكثر تسامحًا.

# 32479 . تحذير حول تحويل string(int) go vet .

تمت إضافة تحويل string(int) النموذج string(int) منذ فترة طويلة إلى Go للراحة ، إلا أنها مربكة جدًا بالنسبة للمبتدئين ( string(10) هي "\n" ، وليس "10" ) ولم يعد هناك ما يبررها ، حيث أصبح التحويل متاحًا في الحزمة unicode/utf8 . نظرًا لأن حذف هذا التحويل ليس تغييرًا متوافقًا مع الإصدارات السابقة ، فإننا نقترح بدلاً من ذلك إلقاء خطأ عند إجراء go vet .

# 32466 . قبول مبادئ تصميم التشفير ( وثيقة التصميم ).

هذا طلب ملاحظات لمجموعة من مبادئ تصميم مكتبة التشفير التي نود قبولها. انظر أيضًا الاقتراح المقابل لإزالة دعم SSLv3 من crypto/tls .

الخطوات التالية

نحن نجمع بنشاط تعليقات على كل هذه الاقتراحات. نحن مهتمون بشكل خاص بالأدلة التي توضح السبب في أن الاقتراح قد لا يعمل بشكل جيد في الممارسة العملية ، أو في الجوانب الإشكالية التي قد فاتنا عند تطويرها. أمثلة مقنعة لدعم الاقتراحات هي أيضا مفيدة للغاية. من ناحية أخرى ، تكون التعليقات التي تحتوي على آراء شخصية فقط أقل فعالية: يمكننا أخذها في الاعتبار ، لكن لا يمكننا العمل معها بشكل بناء. قبل الإجابة ، يرجى قضاء بعض الوقت في قراءة وثائق التصميم التفصيلية والمراجعات السابقة أو ملخصها. ربما يكون قد تم طرح موضوعك ومناقشته بالفعل في التعليقات السابقة ، خاصة خلال المناقشات الطويلة.

إذا كانت هذه المقترحات لا تفي بمشاكل واضحة ، فإننا نخطط لتنفيذ كل شيء في بداية دورة التطوير Go 1.14 (أوائل أغسطس 2019) ، بحيث يمكن بالفعل تقييم ذلك من الناحية العملية. وفقًا لعملية تقييم المقترحات ، سيتم اتخاذ القرار النهائي في نهاية دورة التطوير (أوائل نوفمبر 2019).

شكرًا للمساعدة في تحسين لغة Go!

روبرت جريسمر ، لفريق Go