უკან დაბრუნება
ბლოგპოსტი: რატომ სჭირდება Rust-ს დასახელებული და არასავალდებულო არგუმენტები
SiTech AI Team2 წთ. საკითხავი

ბლოგპოსტი: რატომ სჭირდება Rust-ს დასახელებული და არასავალდებულო არგუმენტები

botahamec.dev-ის ავტორი ამბობს, რომ Rust-ის ყველაზე სუსტი მხარე დასახელებული და არასავალდებულო არგუმენტების არარსებობაა. პოსტი ადარებს Dart-ს, C#-სა და TypeScript-ს და საკუთარ pre-RFC-ს სთავაზობს.

botahamec.dev-ზე გამოქვეყნებულ პოსტში ავტორი აცხადებს, რომ Rust-ის ყველაზე შემაწუხებელი ხარვეზი დასახელებული (named) და არასავალდებულო (optional) არგუმენტების არარსებობაა. ის აღნიშნავს, რომ მისთვის მისაღებ ენებს შორის სწორედ Rust-შია დასახელებული არგუმენტების მიღება ყველაზე ძნელი, და პოსტს საკუთარი pre-RFC-ით ამთავრებს.

როგორ აგვარებენ ამას სხვა ენები

Dart, რომელიც გრაფიკული ინტერფეისებისთვისაა შექმნილი და კომპონენტებს ბევრი არასავალდებულო პარამეტრი აქვს, დასახელებულ პარამეტრებს ფიგურულ ფრჩხილებში ახვევს და იძლევა ნაგულისხმევი მნიშვნელობებისა და `required` მოდიფიკატორის საშუალებას — ავტორის შეფასებით, ეს განხილულ ენებს შორის საუკეთესოა. C#-ში ნებისმიერი პარამეტრის დასახელება ან ნაგულისხმევი მნიშვნელობის მიცემა შეიძლება, თუ ნაგულისხმევები სავალდებულოთა შემდეგ დგას. TypeScript-ში არასავალდებულო პოზიციური პარამეტრები კარგად მუშაობს, დასახელებულისთვის კი ერთი ანონიმური ობიექტის დესტრუქტურიზაციაა საჭირო — ველის სახელები ორჯერ იწერება, რასაც ავტორი ზედმეტ სიტყვიერებად მიიჩნევს.

რა უჯდება Rust-ს ეს ხარვეზი

Rust-ში ჩვეული გზა ცალკე პარამეტრული სტრუქტურა და `Default`-ის იმპლემენტაციაა, გამოძახების ბოლოს კი `..Default::default()` იწერება. ავტორის აზრით, ეს TypeScript-ის ვარიანტზეც უარესია: ტიპები ანონიმური არ არის, სტანდარტულისგან განსხვავებული მნიშვნელობები ცალკე ფუნქციას მოითხოვს და მეთოდი ყველა პარამეტრის ნაგულისხმევობას გულისხმობს.

სამი არასავალდებულო პარამეტრისთვის ბიბლიოთეკის `HashMap`-ს რვა კონსტრუქტორი აქვს, მათ შორის `new`, `with_capacity` და `with_hasher` `_in` ვარიანტებით, და ფუნქციათა რაოდენობა ექსპონენციურად იზრდება. არგუმენტების რიგის დაბნევაც იოლია: `fn print(text: &str, bold: bool, italics: bool, underline: bool)` — მეორე და მესამე არგუმენტის ადგილების შეცვლა ტექსტს შეუმჩნევლად თამამს გახდის.

ავტორის წინადადება

ავტორის pre-RFC დასახელებას არჩევითს ხდის `pub` საკვანძო სიტყვით პარამეტრის სახელის წინ: `fn print_labeled_measurement(pub value: i32, pub unit_label: char = 'm')`; გამოძახება — `print_labeled_measurement(value: 5)`. დასახელებული არგუმენტები პოზიციურის შემდეგ დგას, მაგრამ ერთმანეთში თავისუფლად გადანაწილდება და შეიძლება ნაგულისხმევი მნიშვნელობა ჰქონდეს (`const` ფუნქციებში — კონსტანტური). ტრეიტები დასახელებულ პარამეტრებს იყენებს, იმპლემენტაციამ სახელები უნდა გაიმეოროს, ფუნქციის მაჩვენებლები და `Fn` ტრეიტები კი პოზიციურად რჩება.

სხვა ვარიანტები და ღია კითხვები

პოსტში განხილულია ავტორისთვის ნაკლებად მისაღები ვარიანტებიც: სტრუქტურის ველების ნაგულისხმევი მნიშვნელობები (უკვე Nightly Rust-შია; მანვე დაწერა polyfill ბიბლიოთეკა `feluments`), სტრუქტურული ჩანაწერები, რომლებიც ენის გუნდმა ზედმეტად ძნელად სარეალიზებლად მიიჩნია, Rust Internals Forum-ის გრძელი pre-RFC გადატვირთვების შემოთავაზებით, წერტილით დაწყებული სინტაქსი და C#-ის სტილის კოპირება. ვინაიდან სახელები არჩევითია, უსაფრთხოება დისციპლინის საკითხია; გამოსავლად Clippy-ს ლინტი ან მომავალ გამოცემაში სახელების სავალდებულოობა სახელდება. ღიად რჩება არგუმენტების რიგითობა და ნაგულისხმევი მნიშვნელობების `const`-ობა.

SSiTech

SiTech — AI-გაძლიერებული ვებ დეველოპმენტი

ვქმნით სწრაფ, თანამედროვე ვებსაიტებს და AI-ს ვაერთიანებთ ქართული ბიზნესებისთვის. გაქვთ პროექტი ან კითხვა? სიამოვნებით დაგეხმარებით.