
ბლოგპოსტი: რატომ სჭირდება 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`-ობა.
SiTech — AI-გაძლიერებული ვებ დეველოპმენტი
ვქმნით სწრაფ, თანამედროვე ვებსაიტებს და AI-ს ვაერთიანებთ ქართული ბიზნესებისთვის. გაქვთ პროექტი ან კითხვა? სიამოვნებით დაგეხმარებით.