Rust: الوسائط الافتراضية وسيطات الكلمات الأساسية

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

fn foo(bar: int, qux=2: int, ham=0: uint) { ... }

والتي يمكن تسميتها بعد ذلك بـ foo(1) ، foo(1, 3) ، foo(1, ham=4) ، foo(6, 7, 8) ، إلخ.

تحرير: يرجى الاطلاع على بناء الجملة المقترح من huonw أدناه ، والذي يبدو أفضل بكثير وأكثر اتساقًا مع بناء جملة الإعلان الحالي.

Triage 2016-08-05: لا يوجد تقدم (أعرفه) ، على الرغم من أنه لا يزال أنيقًا ؛ ربما يمكن أن تبدو صيغة الإعلان

fn foo(bar: int, qux: int = 4, ham: Option<int> = None) { ... }

حيث RHS هو أي expr ثابت (أي الأشياء الصالحة في إعلان static ).

IMO هذه مفيدة حقًا ، حتى نظام C ++ الخاص بـ _الوسائط الافتراضية _ حيث يمكنك فقط الرجوع إلى الإعدادات الافتراضية لتتبع الحجج غير المحددة سيكون رائعًا ... أن تكون قادرًا على إعلان تلك الموجودة في الهياكل ومتغيرات التعداد أيضًا سيكون أمرًا رائعًا.
ربما يمكن تنفيذ هذه المجموعة الفرعية الأبسط من السلوك المطلوب قبل أن يكون هناك إجماع حول كيفية / إذا كان سيتم استدعاء معلمات الكلمات الرئيسية المسماة ... هل ستجعل العناصر الداخلية جاهزة؟

هل سيكون قابلاً للتطبيق / مفيدًا للتنفيذ كتعبيرات ... من حيث الوسائط المحددة مسبقًا ومعلمات النوع العام (على سبيل المثال .. القدرة على البحث عن صفر ::، أو اكتب أشياء مثل شريحة (& self ، start: uint ، end: uint = self.len ()) / * "foobarbaz" .slice (6) == "baz" .. أو create_window (الأصل ، x ، y ، العرض : uint = parent.width () / 4، height: uint = (width_161) / 100) / _ الافتراضي هو النوافذ ذات النسبة الذهبية ، وعرض الشاشة 1/4 إذا لم تحدد حجمًا على الإطلاق .. * / .. .. أو هل هذا يبدو وكأنه وصفة لانتفاخ التعليمات البرمجية ..

قد تمنع الإعدادات الافتراضية لأسلوب c ++ تطبيق functoin الجزئي الذي يشبه haskell ، لكنني سمعت أنه من غير المرجح أن يدخل التطبيق؟

إليك فكرة أخرى عن الوسيطات الافتراضية. بدلاً من السماح بإلغاء الوسيطات تمامًا ، نسمح باستدعاء الوسائط التي يوجد لها افتراضي باستخدام _ .

لذلك نظرًا لمثالhuonw الجميل على:

fn foo(bar: int, qux: int = 4, ham: Option<int> = None) { ... }

... يمكننا استدعاء هذا كـ foo(1, 2, None) ، foo(1, _, Some(1)) ، foo(1, _, _) ، إلخ.

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

تغيير العنوان إلى "الوسائط الافتراضية وسيطات الكلمات الرئيسية".

لم يتم تنفيذه ، لكنني حاولت الإضافة إلى المحلل اللغوي & ast؛ https://github.com/dobkeratops/rust/compare/default_args ، هل هذه هي الطريقة الصحيحة للقيام بذلك؟ (الخيار @ expr .. سيحتاج إلى ضوابط على ما يمكن أن يكون expr؟)
غمس أصابع قدمي في الماء لتجربة هذه الميزة.
سأكون حريصًا على هذا لزيادة المجموعة الفرعية من C ++ api التي يمكن ترجمتها ، وهي بالتأكيد شيء أفتقده من C ++ ، وستكون ميزة الكلمات الرئيسية المسماة رائعة بما يتجاوز ما تفعله c ++.
بدا الأمر بسيطًا ومنطقيًا استخدام صيغة الإعلان الثانية المقترحة

dobkeratops يبدو جيدًا (على الرغم من أن type Default = Option<@expr> ربما يكون غير ضروري).

القيود المفروضة على expr تذهب في rustc::middle::check_const ؛ سيتعين عليك إضافة دالة مثل check_fn تتحقق من كل وسيطة. (أيضًا ، من المفترض أن يكون هناك تحقق من أن الوسائط الافتراضية تظهر فقط في النهاية ؛ وأعتقد أنه يجب أن يكون هناك شيء في مدقق النوع rustc::middle::typeck ، وفي trans أيضًا. )

حسنًا ، تمت تسمية الحقل بحيث لا يكون هناك تعليق توضيحي.
شكرا للمؤشرات حول مكان البحث ، كنت أبحث في rustc :: middle :: typeck :: .. mod.rs (check_fn شيء).

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

إنه مدمر فقط إذا قررت بالتأكيد _ ضدهم_؟

اقترح أحدهم أن هذا النوع من الأشياء يمكن أن يدخل مع خيار -Z (.. الجلسة :: debug_opts ... لكني لم أجد هذه العناصر منتشرة حاليًا في كل مكان (على سبيل المثال في المحلل اللغوي).

أستطيع أن أرى أنك قد تعترض على قيام المترجم بتحليل شيء لم يستخدمه بعد ، يمكنني تغييره من تحذير إلى خطأ ربما ...

dobkeratops لاحظ أنه لم يعلق أي مطور رسمي على هذا الأمر حتى الآن ، لذا فمن غير المرجح أن يتم قبول أي

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

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

هناك الكثير من الأجزاء الدقيقة هنا. أي وسيطات افتراضية هي شكل ضمني من التحميل الزائد ، لذلك (أظن) من المحتمل أن تتكامل مع خوارزمية دقة السمات و / أو كتابة الاستدلال. قد لا يكون الأمر صعبًا للغاية ولكنه يستحق التصميم الدقيق ، وفي هذه المرحلة لست متأكدًا من أن لدينا ميزانية زمنية لذلك. بصفتي ميزة لغة ، أتخيل أنها متوافقة مع الإصدارات السابقة ؛ كميزة api ، فمن المحتمل أن يُعلم تصميم API البعض ، لذلك يمثل مخاطر bc.

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

ومع ذلك ، على عكس Rust ، فإن Go لديه بعض الميزات التي تجعل غياب الحجج الافتراضية أقل إيلامًا. أولاً ، لديهم وظائف متنوعة. [1] ثانيًا ، يُسمح لك بحذف الحقول عند إنشاء الهياكل ، مما يعني أنه من السهل تمرير بنية التكوين إلى وظيفة (يبدو أن الحقول المحذوفة مضبوطة على القيم الافتراضية المحددة من قبل المترجم (؟) ، بدلاً من أن تكون شيئًا يمكن للمستخدم تخصيص). [2]

بالنسبة للأولى ، قد نتمكن من التخلص من القرصنة الكلية لتحقيق نفس النتيجة (على الرغم من تكلفة التنفيذ الشاقة). في الواقع ، البديل القادم fmt!() يفعل هذا:

ifmt!("{foo} {1} {bar} {0}", 0, 1, foo=2, bar=3)

هذا هو الرمز الذي يعمل اليوم.

بالنسبة إلى الأخير ، فإن أفضل نظير لدينا هو استخدام تحديث البنية الوظيفية وفقًا لما يلي:

struct Foo { x: int, y: int, z: int }

impl Foo {
    fn default() -> Foo {
        Foo{x: 0, y: 0, z: 0}
    }
}

fn bar(f: Foo) {
    printf!(f);
}

fn main() {
    bar(Foo{y: 5, ..Foo::default()});
}

لقد رأيت هذه الطريقة مقترحة بشكل غير رسمي في الماضي كحل بديل لنقص الحجج الافتراضية ، لكنها غير مجدية في الممارسة العملية (قارن bar(Foo{y: 5, ..Foo::default()}) بـ bar(y=5) ، أو اقتراحي الأكثر تحفظًا بـ bar(_, 5, _) ) ، وبالطبع فإنه يفرض على جميع المتصلين إنشاء بنية حتى لو كانوا يريدون تمرير جميع المتغيرات.

للتكرار ، بصفتي شخصًا يأتي من Python و Javascript ، من الواضح أنني أرحب بالحجج الافتراضية. ومع ذلك ، فأنا أتعاطف إلى حد ما مع فلسفة Go في جعل واجهات برمجة التطبيقات صريحة (في مقابل (من المحتمل بشكل كبير) تضخيم عدد الوظائف في واجهة برمجة التطبيقات نفسها).

[1] https://groups.google.com/d/msg/golang-nuts/NWMReL1HueQ/X9mdYduCOB8J

[2] http://stackoverflow.com/questions/2032149/optional-parameters

يجب أن أشير أيضًا إلى أنه يتفاعل مع عمليات الإغلاق وأخذ مراجع الدرجة الأولى للوظائف.

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

وأنا أتفق نوعًا ما على أن وظائف الغلاف لملء الفراغات الافتراضية ليست سيئة للغاية في بعض الحالات. لكن المشكلة تكمن في أنه يوفر عليك من بعض الحالات المربكة ، إلا أنه يقدم الكثير من النماذج المعيارية في حالات أخرى. أحد الأمثلة هو *::to_str_radix(num, radix) . إذا كان لدينا وسائط اختيارية ، فيمكن طيها في *::to_str(num, radix = 10) . أشعر أنه في بعض الحالات ، يؤدي انفجار متغيرات الوظائف إلى جعل الأشياء أقل بديهية ويصعب تذكرها. فقط سنتي على الرغم من الواضح.

أستطيع أن أرى أن الوقت مناسب للمقايضة لتأجيلها ؛
ولكن هل يتجاهل _ حقًا_ الإعدادات الافتراضية فلسفيًا ، أم أن هذا فقط يبرر تنفيذ المقايضات الخاصة بالموازنة الزمنية التي قاموا بها؟ سأندهش إذا اعتقد أي شخص أن الخوض في long_function_names_with_lots_of_trailing_qualifiers هو خطوة للأمام :) ، ولكن إذا قالوا "يتيح لنا الاستفادة من الأدوات البسيطة ، فنحن لم نطور IDE قويًا حتى الآن .." فهذه مسألة أخرى.

من المؤكد أنني أفتقد كل من التحميل الزائد والافتراضات من C ++ .. ولكني كنت سعيدًا لاستبدالها بمقابلات Rusts الأخرى والوعد ببديل C ++ (بعد أن كنت عالقًا مع لغة رئيسية واحدة لفترة طويلة ..)

بالنسبة لتجربة فكرت في محاولة إجراؤها كـ "قرصنة محلل" ... تعمل على مستوى وحدات الماكرو؟ تضمين expr الافتراضي في مواقع الاتصال حيث الوسائط مفقودة؟
أدرك أنه من غير المحتمل أن يكون تصميمًا مقبولاً - لكنه يجعلني أصدق أنه ليس من الممكن أن يكون لديك حجرات افتراضية تعمل مع ميزات الصدأ.

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

فقط حتى لا تختفي الفكرة: يبدو أن الجانب الثرثار لـ bar(Foo{y: 5, ..Foo::default()}) هو الجزء ..Foo::default() .

إذا جعلنا من الأسهل ترك الحقول في بناء الهيكل ، وتركناها تنخفض إلى الوضع الافتراضي ، فربما يكون هذا النهج أكثر قبولا.

على سبيل المثال ، شكل جديد ، ربما تم تعريفه فقط للهياكل التي تنفذ بعض السمات المناسبة ( Zero أو Default أو أيًا كان) ، والتي بدت كما يلي:

Foo{y: 5, *) حيث يحل * مكان ..Foo::default() .

ثم المثال هو "فقط" bar(Foo{y: 5, *}) . ربما يفضل الآخرون عدم وجود Foo ليس هناك أيضًا ، لكن هذا يبدو نظيفًا جدًا بالنسبة لي.

أفترض أن التعدادات تمنحك أيضًا بعض الطرق الأخرى لتمرير مجموعات من المعلمات الاختيارية بشكل ملائم بشكل مختلف عما يستخدمه مبرمج C ++ ... وطريقة لتقسيم التعليقات التوضيحية والقيم مع استدعاء.
يبدو أن هذا يناسب الحالات مثل إنشاء شيء به الكثير من معلمات الإعداد جيدًا

pnkfelix تذكر أن Foo في هذا المثال من المحتمل أن يكون له اسم وصفي ذاتي أكثر بكثير ، وحتى مع السكر الذي تقترحه سيبدو مثل هذا في الممارسة العملية:

html::start_server(html::ServerOpts{port: 10088, *});

يبدو أجمل قليلا. ما زلت غير متأكد ما إذا كان يساعد بدرجة كافية لتبرير بناء جملة جديد ، أو ما إذا كان كافياً لتلبية جميع حالات استخدام الحجج الافتراضية.

في الواقع ، لاستخدام المثال الخاص بي ، عند تهيئة شيء ما باستخدام الكثير من الخيارات مثل خادم HTML ، من المحتمل أن أكون سعيدًا تمامًا بإعداد بنية server_opts مسبقًا ثم استدعاء start_server(server_opts) . ولا أمانع حقًا في إضافة سطر بـ ..html::ServerOpts::default إذا كانت تهيئة الهيكل الخاصة بي تمتد بالفعل إلى عدة أسطر.

أعتقد أننا ربما نحتاج إلى إعادة التفكير في المواضع التي ستكون فيها الحجج الافتراضية مفيدة للغاية. بالنسبة لي ، ليس هناك الكثير من الحجج المحتملة ؛ يجب أن تكون هذه نادرة إلى حد ما ، ولا بأس ببضعة أسطر لبدء بنية التكوين. بدلاً من ذلك ، أفتقد معظم الحجج الافتراضية عندما تكون 1) العملية شائعة إلى حد ما ، و 2) تحتوي العملية ، على الأكثر ، على واحد أو اثنتين من الحجج التي تكون دائمًا غير ضرورية ولكنها مطلوبة للكمال. فمثلا:

let foo = Some('a');
foo.unwrap();  // same as today
foo.unwrap('z');  // imagine that this replaced unwrap_or_default

int::from_str("4");  // same as today
int::from_str("4", 16);  // imagine that this replaced from_str_radix

ومع ذلك ، الآن بعد أن قمت بكتابتها ، أفضل في الواقع توضيح الطرق المنفصلة. :) ربما لا أعرف حقًا ما أريد بعد كل شيء!

dobkeratops ، من تجربتك مع C ++ ، هل يمكنك أن تعطينا بعض الأمثلة على واجهات برمجة تطبيقات C ++ لطيفة التي يتم تمكينها بواسطة الوسائط الافتراضية؟

يبدو أن التعليقات في https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-08-13 تشير إلى أن المطورين يرون هذا كميزة مستقبلية بعيدة. الترشيح.

يقوم OCaml بعمل حجة اختيارية / افتراضية دون زيادة التحميل ، على ما أعتقد. يتم تحويل الوسائط الاختيارية من النوع T بدون قيمة افتراضية بشكل ضمني إلى خيار T ويجب أن تتحقق الوظيفة من توفير قيمة. هناك أيضًا قيود على الإعلان عن الوسيطات الاختيارية واستخدامها لجعل المترجم يعرف متى تم حذف الوسيطة. يجب أن تحتوي جميع الوسائط الاختيارية على تسميات (يجب أن تكون وسيطات كلمات رئيسية حتى تكون اختيارية). يؤدي هذا إلى تعقيد نظام نوع OCaml (تصبح الملصقات جزءًا من نوع الوظيفة) ، لكنني أعتقد أن هذه نتيجة لضرورة التعامل مع بقية نظام نوع Hindley-Milner.

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

أوافق على أن الحجج الافتراضية و / أو وسيطات الكلمات الرئيسية ستكون مفيدة للغاية. أعتقد أننا يجب أن نعمل من أجل اقتراح ما قبل الإصدار 1.0 الذي يحدد ما يجب القيام به فيما يتعلق بالحمل الزائد وربما إجراء مناقشة حول التركيب اللغوي.

من الجيد أن نرى المزيد من الأشخاص يعلقون لصالح :) سبب آخر كنت أرغب فيه هو زيادة كمية واجهات برمجة تطبيقات C ++ التي يمكن ترجمتها بسلاسة. يعد استخدام مكتبات C ++ أحد الأسباب الرئيسية التي تجعلنا عالقين في C ++.

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

هذا هو السبب في أنني أردت تقديم العمل الأساسي لتحليلها في بنية بيانات AST. سيكون جاهزًا لشخص آخر لاستلامه ومحاولة الحصول على حل. ردود الفعل الأولية لا تشجعني على إجراء العلاقات العامة.

من ++ C ، ألقي نظرة حسد على ما يمتلكه سكالا وثعبان. ستكون لغة أصلية غير GC مع هذه الأناقة رائعة.
.. المزيد من الوظائف في مكان واحد ، وأقل تنقلًا لمعرفة ما يحدث ، وعمق أقل للتداخل ، وضوضاء أقل في رمز المصدر. ليس فقط أقل تافهة الكتابة.
ربما يمكنك حتى المطالبة بتوثيقها الذاتي بشكل أكبر ، يخبرك توقيع الوظيفة بالمزيد حول كيفية استخدامها.

الجزء الصعب هو مدقق النوع ، مما يمنع احتمالات الأخطاء الدقيقة والأخطاء المربكة إذا تم القيام به للتو كاختراق محلل ، كما يعتقد.

تخيل لو كان بإمكانك كتابة أشياء كهذه ..

fn substr(a:&str, start:int, end:int=a.len())->~str

فقط اخترق هذا النوع من الأشياء في AST دون التحقق من الأخطاء ، أنا متأكد من أن الكثير يمكن أن يحدث بشكل خاطئ .. ولكن تخيل ما إذا كان بإمكاننا إصلاح ذلك لفعل ما كان متوقعًا :)

مجرد خطأ. يمكننا مناقشة المزايا ، لكننا لن نمنع إصدارها.

أحب السلوك الذي يصفه tautologico في تعليقه.

بالتطبيق على Rust ، أعتقد أن هذا سيترجم إلى ما يلي:

fn ga(bu: int, zo: Option<int>, meu: Option<int>) {
  let zo = zo.get_or_default(42);
  let meu = meu.get_or_default(99);
  ...
}

وستكون هذه كلها مكالمات صالحة:

ga(10, 20, 30); // 20 and 30 are automagically
                // converted to Some(20) and Some(30)
ga(10, 20);         // ga(10, 20, 99) 
ga(10);             // ga(10, 42, 99)
ga(10, None, None); // ga(10, 42, 99)
ga(10, 20, None);   // ga(10, 20, 99)
ga(10, None, 30);   // ga(10, 42, 30)

القاعدة هي أنه يمكن حذف المعلمات اللاحقة Option<T> . هنا ، يتم إعادة استخدام النوع Option ، ولكن إذا تسبب هذا في بعض المشاكل ، فيمكن إنشاء نوع OptParam آخر أكثر تحديدًا.

يسمح هذا الاقتراح للمتصل بالاختيار الدقيق للمعلمات التي يريد توفيرها وتلك التي يريد الاحتفاظ بها متخلفة ، بصرف النظر عن موقعه. أيضًا ، أعتقد أنه من الجيد ألا تظهر القيمة الافتراضية في قائمة المعلمات. بهذه الطريقة ، لا تقتصر القيمة الافتراضية على تعبير ثابت ، بل يمكن أن تعتمد على حالة الكائن ، أو يمكن أن تعتمد على معلمات أخرى.

مثال واقعي لوظيفة تعرض مربع حوار واجهة المستخدم الرسومية:

fn showDialog(message: ~str,
              parent: Option<Widget>,
              title: Option<~str>,
              type: Option<DialogType>,
              icon: Option<Icon>) { ... }

// Display an info box in the middle of the screen.
// Set the title to "information", translated in the current locale
// Set the icon to an "info" icon
showDialog(~"hello, world!");

// Display a warning box in the middle of the screen.
// Set the title to "warning", translated in the current locale
// Set the icon to a "warning" icon
showDialog(~"sick, sad world!", None, None, WarningDialog);

// Display a warning box in the middle of the screen.
// Set the title to "warning", translated in the current locale
// Set the icon to a custom icon
showDialog(~"sick, sad world!", None, None, WarningDialog, bugIcon);

في هذا المثال:

• القيمة الافتراضية لـ parent هي None (بدون أصل)
• القيمة الافتراضية لـ type هي InfoDialog
• القيمة الافتراضية icon تعتمد على قيمة type
• القيمة الافتراضية title تعتمد على قيمة type وعلى اللغة الحالية

أنت الآن تقترح أيضًا إضافة Option كنوع أساسي جديد. إنها ميزة مكتبة بالكامل في الوقت الحالي ، حيث إنها ميزة قديمة enum .

أود أن أضيف أن الوسائط الافتراضية لـ IMO أفضل بمليار مرة باستخدام args للكلمات الرئيسية. لا تعجبني فكرة args الافتراضية ولكن لا توجد كلمات مفتاحية args.

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

ينتج عن القيم الافتراضية للوسيطات الموضعية رمز مشفر. لماذا لا يقتصر الأمر على الافتراضيات لوسائط الكلمات الرئيسية؟ (إذا تم تنفيذ هذه).

المنظمة البحرية الدولية ... إنها ليست "إما أو".
كلاهما مفيد. واحد أسهل في التنفيذ ، مع خيارات أقل في بناء الجملة ؛
لذلك من المنطقي بالنسبة لنا القيام بذلك ، أو محاولة تنفيذه أولاً ، كنقطة انطلاق ...

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

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

هذا بالطبع ليس صحيحًا بشكل عام: غالبًا ما يكون لدى المرء بعض الحجج المطلوبة والبعض الآخر اختياري.

ما زلت أرغب في اكتشاف طريقة ما للاستفادة من الميزات التي لدينا بالفعل ، بدلاً من التلاعب بشكل أكبر بصيغة إعلان الوظيفة ، ويرجع ذلك أساسًا إلى أن إعلانات الوظائف _المشعرة بالفعل_ بفضل الطرق المختلفة التي يمكن للمرء أن يكتب بها الوظائف / الإغلاق / الطرق.

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

struct Foo { x: int = 0, y:int = 0, z:int = 0 }

fn bar(f: Foo) {
    printf!(f);
}

struct Baz { x: int, y: int, z:int = 0 }

fn quux(g: Baz} {
    printf!(g);
}

fn main() {
    bar(Foo{y: 5});
    quux(Baz{y: 5}); // ~ERROR: required field, `x`
}

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

fn bar({ x: int = 0, y:int = 0, z:int = 0 }) {
    printf!(f);
}

fn quux({ x: int, y: int, z:int = 0 }) {
    printf!(g);
}

fn main() {
    bar({ y: 5 });
    quux({ y: 5 }); // ~ERROR: required field, `x`
}

visionmediabstrie هل نحن حقا في حاجة إلى أن تشعر بالقلق إزاء التخلص من اسم البنية؟ ألا يحل إعلان استخدام إعادة الربط مشكلة الأسماء الطويلة ، وذلك بتخفيض الحد الأدنى لعدد الأحرف الإضافية في موقع الاستدعاء إلى 3 (للاسم + الأقواس اليمنى واليسرى)؟

أي مع مثال ServerOpts الذي طرحه لي bstrie:

fn main() {
  use O = html::StartServerOptions;
  ...
  html::start_server(O{port: 10088});
}

pnkfelix أنا أحب

struct Foo {
   x: int = 10,
   y: float = 1.0
}

بناء الجملة ، لكنني لا أعتقد أننا بحاجة إليها للحصول على حجج إجبارية معقولة (لسوء الحظ لم يتم ذكر اسمها) ، فقط قم بتمرير الحجج الإجبارية بشكل منفصل:

struct FooOptions { ... }
static default: FooOptions = FooOptions { ... };
fn foo(compulsory: int, required: uint, necessary: float, optionals: FooOptions) { ... }

FWIW ، أنا أيضًا أحب فكرة البنية ذات القيم الافتراضية. أعتقد أن هذا سيكون اختصارًا لـ:

struct Test {
    m: int,
    y: int
}

static DEFAULT: Test = Test{m: 10, y: 15};

Test{y: 5, ..DEFAULT}

يعجبني الهيكل الافتراضي داخل التعريف أيضًا

لقد حصلت على هذا التحليل باستخدام هذا النحو أيضًا ولكن لم يتم استخدامه في الواقع .. ما زلت لا أعرف طريقي حول مصدر مدقق الحروف وما إلى ذلك ...

ربما حقيقة وجود آلية افتراضية بالفعل قد تجعل من السهل تنفيذها قليلاً.

إعادة. الهياكل المجهولة أعتقد أنها كانت تمتلك هذه في الأصل ولكن كان عليها إزالتها "بسبب تفاعلات غريبة"؟
أنا أفضل أن يكون كلتا الآليتين متاحتين. ربما تخفف بنيات المعلمات من الحاجة إلى وسيطات _keyword_ ، لكن الافتراضيات اللاحقة مثل في c ++ ستظل سهلة

كمرجع -
http://www.parashift.com/c++-faq-lite/itled-parameter-idiom.html
لول - مثيرة للاهتمام ولكن الحجج الكلمات الرئيسية الحقيقية من شأنها تجنب الحاجة إلى الاختراقات الثقيلة مثل هذا

إعادة. الهياكل المجهولة أعتقد أنها كانت تمتلك هذه في الأصل ولكن كان عليها إزالتها "بسبب تفاعلات غريبة"؟

في الأصل كانت جميع أنواع الهياكل هيكلية. لقد تمت إزالتها (استبدالها بأنواع الهياكل الاسمية) بسبب التفاعلات المحرجة مع السمات ، على ما أعتقد.

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

قادمة من Perl (حيث تكون الافتراضيات نمطًا مخصصًا) ، Python 2 (حيث يمكنك الحصول على foo() takes at least 2 arguments (2 given) ) ، و Python 3 (حيث يمكنك الحصول على وسيطات مسماة فقط _ بدون _ افتراضيات) ، أقترح بتواضع: add _teeny_ bit من السكر للسماح بالتصريح عن بنية باعتبارها الوسيطة النهائية للدالة ، ولكن دع المتصل _inline_ الحقول Struct.

على سبيل المثال

impl int {
    struct FromStrOptions {
        radix: uint = 10
    }
    fn from_str(s: str, opts: FromStrOptions) -> int {
        // ...
    }
}

int::from_str("4", radix: 10);

مزايا:

• لا توجد صيغة جديدة لتعريف الوظيفة ، والتي لا يجب أن تهتم على الإطلاق بالطريقة التي يسميها المتصل. هذا مشابه لكيفية عمل تمرير الكتل باستخدام do : إنه مصدر قلق المتصل فقط. (هل يجب أن تكون هناك طريقة للاشتراك / عدم الاشتراك ، في حالة وجود حجة أخيرة عبارة عن بنية ولكن لا تنوي استخدامها مع kwargs؟ هل سيهتم أي شخص؟ لا أعتقد أن أي شخص يهتم do .)
• لا يزال التخطيط الثنائي ودلالات استدعاء C وما إلى ذلك محددة جيدًا.
• لم يعد التحميل الزائد حسب النوع أو arity أكثر صعوبة في التنفيذ يومًا ما ، باستثناء أن نوع الوسيطة النهائية لا يمكن أن يساهم في زيادة التحميل على الكتابة. لا ينبغي أن تتداخل مع الحجج المتغيرة ، إذا حدث ذلك على الإطلاق.
• يمكن إعادة استخدام نفس مجموعة الإعدادات الافتراضية في وظائف متعددة.
• شيء مثل **kwargs مجانًا: ما عليك سوى إنشاء البنية ومررها على أنها وسيطة موضعية بدلاً من ذلك.
• تنبع وسيطات الكلمات الرئيسية المطلوبة بشكل طبيعي من هذا: فقط لا تعطي قيمة افتراضية في البنية ، وستكون مضطرًا لتمرير _something_ بالاسم.
• لا لبس أحمق عند تمرير الحجج الموضعية بالاسم ؛ لا يمكنك فعل ذلك.

سلبيات:

• سحري بعض الشيء. ولكن ليس أكثر من تمرير 5 والحصول على النوع المستنتج من argspec للوظيفة ، على ما أعتقد.
• من غير الواضح كيف سيتفاعل مع المصطلح الحالي do . قد يكون من السهل القول بأنه يجب أن تكون الوسيطة الأخيرة _written_ ، أي أنها تعمل كوسيطة من الثانية إلى الأخيرة فقط عند استخدامها مع do .

قد يتعارض FWIW int::from_str("4", radix: 10) مع ، المقترح مسبقًا ، استخدام : كنوع عامل الإسناد.

اللعنات التي أحبطتها ASCII.

int::from_str("4", radix☃ 10)

كنت سأصوت لاستخدام = لـ Args الكلمات الرئيسية ، فقط لا تسمح بفكرة C الخاصة بالتخصيصات داخل التعبيرات الفرعية .. (والتي ربما لا تتناسب كثيرًا مع أفكار الصدأ غير القابلة للتغيير على أي حال) .. أعتقد أن Scala لديه هذا ، من أجل مثال محتمل لكيفية تناسبها في بناء جملة مثل c؟

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

تحدثنا عن هذا في الاجتماع الأسبوعي

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

قرر الفريق أيضًا أن حل هذا بأي طريقة ليس من أولويات الإصدار 1.0. اقترح قائد المشروع

هذا تلميح قوي لجميع المساهمين: اخترق كل ما تريد ، ولكن من فضلك لا ترسل طلبات السحب أو r + أي شيء لهذا الخطأ حتى بعد الإصدار 1.0.

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

اسمحوا لي أن أوضح.

وسائط الوظيفة الافتراضية هي _critical_ لتصميم جيد لواجهة برمجة التطبيقات ؛ يؤدي عدم وجودها إلى تعقيد ما يمكن أن يكون أبسط واجهات برمجة تطبيقات. أمثلة من مكتبة الأمراض المنقولة جنسياً:

• concat و connect بدلاً من concat التي تأخذ فاصل اختياريًا.
• split_iter و splitn_iter أكثر من split_iter مع count اختياري. نفس الشيء مع rsplit_iter و rsplitn_iter .

و اخرين.

يؤدي وجود كل أسماء الوظائف الإضافية التي يمكن إزالتها باستخدام الوسائط الافتراضية إلى زيادة العبء المعرفي دون داع. يتعين على المستخدم الآن معرفة اسمين (أو أكثر) بدلاً من اسم واحد.

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

حتى يظل هذا العبء المعرفي الإضافي _ للأبد_.

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

Rust devs ، شكرًا للعمل على Rust وجعله رائعًا!

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

https://github.com/mozilla/rust/issues؟milestone=12&state=open

أو أحد الأخطاء الـ 104 المفتوحة في الإنجاز 2 (التوافق مع الإصدارات السابقة):

https://github.com/mozilla/rust/issues؟milestone=13&state=open

أو واحد من 68 خطأً مفتوحًا في الإنجاز 3 (الميزات التي اتفقنا عليها في وقت ما ضرورية لإصدار Rust 1.0):

https://github.com/mozilla/rust/issues؟milestone=14&state=open

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

أستطيع أن أرى أن الفريق الأساسي لديه أشياء أكثر أهمية ليقوم بها ، لكن يبدو أنه من العار "التعبير عن الإحباط الشديد" :(
+1 لتعليقات vallorics. التسمية صعبة ، والتنقيب عن طريق التوثيق ومعرفة المزيد من الأسماء هو قطع ..؛ تراكب / تراكب افتراضية تجعل الأمر أسهل ؛ باستخدام args ، ستتاح لك الفرصة لتجاوز C ++ في هذا الشأن. (أتمنى لو كان لدى جيثب تصويت ، يمكنني فقط الضغط على +1 بدلاً من الصراخ أكثر قليلاً هنا لول)

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

لا يوجد إجماع على أن هذه ستكون ميزة لغوية جيدة. لا يوجد أيضًا اقتراح ملموس مع وضع جميع التفاصيل للمعلمات المسماة / الافتراضية. لن يحدث هذا مع الإصدار 1.0 ، نظرًا لوجود مجموعة حالية من ميزات اللغات الأساسية لإصلاحها أو إزالتها قبل أن نحلم بسكر نحوي غير أساسي.

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

لن يحدث هذا مع الإصدار 1.0 ، نظرًا لوجود مجموعة حالية من ميزات اللغات الأساسية لإصلاحها أو إزالتها قبل أن نحلم بسكر نحوي غير أساسي.

أنا لا أقول أن ميزات اللغة الأخرى التي تحتاج إلى الإصلاح / التنفيذ ليست أكثر أهمية ؛ هم على الأرجح. لكنها ليست إما / أو. كل ما أقوله هو أنه يجب النظر بشدة في هذه الميزة لـ 1.0 (بالإضافة إلى الميزات الأخرى) لأن عدم وجودها يؤثر على جودة واجهات برمجة التطبيقات في مكتبة الأمراض المنقولة جنسياً _ للأبد_.

ربما يكون هذا رأيًا مثيرًا للجدل ، لكن لغات برمجة IMO تعيش وتموت بسبب واجهات برمجة التطبيقات التي توفرها أكثر من الميزات الأساسية فيها. باعت مكتبة بايثون "البطاريات المضمنة" اللغة بأكملها. CPAN يبقي Perl على قيد الحياة. يجعل .Net كتابة كود C # رائعًا ، و LINQ هو أفضل شيء منذ تقطيع الخبز. أحد أعظم إخفاقات C ++ هو الافتقار إلى واجهات برمجة تطبيقات جيدة وموحدة. إلخ.

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

dobkeratops : بقولي _dreaming up_ ، أحاول التأكيد على أنه لم يتم تقديم أي اقتراح كامل ، لذا فهو ليس في خطوة اتخاذ القرار

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

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

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

thestingercatamorphism شكرا لكما على الحفاظ على ذهن متفتح! عندما أجد بعض الوقت ، سأقوم بإعداد اقتراح وإرساله إلى rust-dev.

لقد أنشأت لوحة لمناقشة هذه الميزة وكتابة مواصفات واضحة عنها: https://pad.riseup.net/p/hvbg6dQQnEe7

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

brson شكرا لك!

لقد قمت بتحرير الإصدار الأصلي برابط إلى etherpad.

مرحبا.
منذ إنشاء اللوحة ، تم إكمالها بالعديد من مقترحات التصميم والأسئلة والمشكلات ، إلخ ...
لذلك قمت بإنشاء لوحة ثانية "لتلخيص" لوحة المناقشة ، سيتم استخدام هذه اللوحة لوصف طلب الميزة بالضبط.
لوحة URL هنا: https://pad.riseup.net/p/Ca5PBeDjUGxW

KokaKiwi كل الفوط فارغة الآن. أين ذهبت المحتويات؟

cmr ، أعتقد:

تحذير: سيتم حذف هذه اللوحة إذا مرت 30 يومًا دون أي تعديلات. لا توجد طريقة لاستعادة الوسادة بعد حدوث ذلك ، لذا كن حذرًا!

:عابس:

أنا في الواقع أبحث في اللوحة التي قمت بإنشائها على مثيل Mozilla Etherpad (لمنع هذه الحالة) ، لكن لا يمكنني العثور عليها في السجل الخاص بي ، ونسيت نشر الرابط هنا :(

cmrhuonwKokaKiwi، وهنا اثنين من وصلات في بلدي متصفح التاريخ:

https://etherpad.mozilla.org/CQEDa85jLX
https://etherpad.mozilla.org/78FA1bozLd

dram هذا ما كنت أبحث عنه! شكرا: مبتسم:
ربما يجب تحرير المشكلة بالروابط الجديدة ، على ما أعتقد.

(محرر.)

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

يجب عمل اقتراح ملموس من خلال عملية RFC الجديدة: https://github.com/rust-lang/rfcs

هناك الكثير من الأفكار المتضاربة وخيوط المحادثة المتباينة هنا لتكون منطقة مناقشة مفيدة.