فهم مشكلة الاستدلال C# كما هو موضح في مواصفات اللغة

Question

ال C# مواصفات اللغة يصف نوع الاستدلال في القسم §7.5.2. هناك تفاصيل لا أفهمها. النظر في الحالة التالية:

// declaration
void Method<T>(T obj, Func<string, T> func);

// call
Method("obj", s => (object) s);

يستنتج كل من مجمعات Microsoft و Mono C# بشكل صحيح T = object, ، لكن فهمي للخوارزمية في المواصفات سوف تسفر T = string ثم تفشل. إليكم كيف أفهمها:

المرحلة الأولى

• إذا كانت EI وظيفة مجهولة استنتاج نوع المعلمة الصريح (§7.5.2.7) مصنوع من EI إلى Ti

  ⇒ ليس له أي تأثير ، لأن تعبير Lambda ليس له أنواع معلمات صريحة. حق؟

• خلاف ذلك ، إذا كان لدى EI نوع u و xi هو معلمة قيمة ثم أ الاستدلال المنخفض مصنوع من u إلى ti.

  ⇒ المعلمة الأولى من النوع الثابت string, ، لذلك هذا يضيف string إلى الحدود السفلية ل T, ، حقا؟

المرحلة الثانية

• الجميع غير مثبت اكتب المتغيرات XI التي لا تفعل ذلك يعتمد على (§7.5.2.5) يتم إصلاح أي XJ (§7.5.2.10).

  ⇒ T غير مثبت. T لا يعتمد على أي شيء ... لذا T يجب أن تكون ثابتة ، أليس كذلك؟

§7.5.2.11 إصلاح

• تبدأ مجموعة أنواع المرشحين UJ كمجموعة من جميع الأنواع في مجموعة الحدود لـ XI.

  ⇒ { string (الأدنى) }

• ثم ندرس كل ملزمة لـ XI بدوره: [...] لكل حدود منخفضة من الحادي عشر من الأنواع UJ التي لا يوجد فيها تحويل ضمني من U من مجموعة المرشحين. [...

  ⇒ لا يزيل أي شيء من مجموعة المرشحين ، أليس كذلك؟

• إذا كان من بين أنواع المرشحين المتبقية UJ ، فهناك نوع فريد من النوع V والذي يوجد منه تحويل ضمني لجميع أنواع المرشحين الأخرى ، ثم يتم إصلاح XI إلى V.

  ⇒ نظرًا لوجود نوع مرشح واحد فقط ، فهذا صحيح بشكل خاطئ ، لذلك يتم إصلاح XI string. حق؟

---

فأين سأخطئ؟

Answer 1

تحديث: كان التحقيق الأولي الخاص بي في الحافلة هذا الصباح غير مكتمل وخاطئ. نص مواصفات المرحلة الأولى صحيح. التنفيذ صحيح.

المواصفات خاطئة من حيث أنها تخطئ ترتيب الأحداث في المرحلة الثانية. يجب أن نحدد أننا نجعل استنتاجات نوع الإخراج قبل نصلح المعلمات غير المعتمدة.

رجل ، هذه الأشياء معقدة. لقد أعادت كتابة هذا القسم من المواصفات مرات أكثر مما يمكنني تذكره.

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

سأعمل مع MADS لتحديث المواصفات لمطابقة التنفيذ. أعتقد أن الصياغة الصحيحة للمرحلة الثانية يجب أن تذهب شيء من هذا القبيل:

• إذا لم تكن هناك معلمات نوع غير مثبت ، فسينجح الاستدلال.
• خلاف ذلك ، في حالة وجود وسيط واحد أو أكثر من الوسائط EI مع نوع المعلمة المقابل TI بحيث يحتوي نوع الإخراج من EI مع Ty Ty Ti على معلمة نوع واحد على الأقل غير مثبت XJ ، ولا يوجد أي من أنواع الإدخال من EI مع Ty Ti يحتوي على أي معلمة نوع غير مثبت XJ ، ثم يتم استدلال نوع الإخراج من كل هذه EI إلى Ti.

سواء كانت الخطوة السابقة قد استدللت بالفعل أم لا ، يجب علينا الآن إصلاح معلمة نوع واحد على الأقل ، على النحو التالي:

• إذا كان هناك واحد أو أكثر من المعلمات من النوع XI بحيث يكون XI غير مثبت ، ولديه XI مجموعة غير فارغة من الحدود ، ولا يعتمد XI على أي XJ ثم يتم إصلاح كل XI من هذا القبيل. في حالة فشل أي عملية إصلاح ، يفشل اكتب الاستدلال.
• خلاف ذلك ، إذا كانت هناك معلمات نوع أو أكثر من النوع XI بحيث تكون XI غير مثبتة ، ولديه XI مجموعة غير فارغة من الحدود ، وهناك معلمة نوع واحد على الأقل XJ تعتمد على XI ثم يتم إصلاح كل XI من هذا القبيل. في حالة فشل أي عملية إصلاح ، يفشل اكتب الاستدلال.
• خلاف ذلك ، نحن غير قادرين على إحراز تقدم وهناك معلمات غير مثبتة. فشل الاستنتاج يفشل.

إذا لم يفشل الاستدلال أو ينجح ، فسيتم تكرار المرحلة الثانية.

الفكرة هنا هي أننا نريد التأكد من أن الخوارزمية لا تدخل في حلقة لا حصر لها. في كل تكرار للمرحلة الثانية ، فإنه ينجح أو يفشل أو يحقق تقدمًا. لا يمكن أن يحلق مرات أكثر مما توجد معلمات نوع لإصلاح الأنواع.

شكرا للفت انتباهي لهذا الموضوع.