Cộng đồng lập trình Rust đang tích cực thảo luận về một hạn chế lâu đời trong các derive macro của ngôn ngữ, đặc biệt là xung quanh trait Clone. Cuộc tranh luận tập trung vào việc liệu cách tiếp cận hiện tại của Rust có bị lỗi cơ bản hay chỉ đơn giản là một sự đánh đổi hợp lý mà các nhà phát triển đã học cách làm việc xung quanh.
Vấn đề cốt lõi với hành vi Derive hiện tại
Khi bạn sử dụng #[derive(Clone)] trong Rust, trình biên dịch yêu cầu tất cả các tham số generic phải implement Clone, ngay cả khi những tham số đó có thể thực sự không cần được clone. Điều này tạo ra những hạn chế không cần thiết ngăn cản code biên dịch trong những trường hợp mà về mặt logic nó nên hoạt động. Ví dụ, một wrapper xung quanh Arc<T> không thể derive Clone mặc dù bản thân Arc<T> có thể clone được bất kể T có implement Clone hay không.
Cộng đồng đã xác định đây là một vấn đề phổ biến không chỉ ảnh hưởng đến Clone, mà còn các trait có thể derive khác như PartialEq, Eq, và Debug. Điều này buộc các nhà phát triển phải viết các implementation thủ công cho những gì lẽ ra nên là các derivation tự động đơn giản.
Hành vi Derive hiện tại so với Derive hoàn hảo
| Khía cạnh | Derive hiện tại | Derive hoàn hảo |
|---|---|---|
| Ràng buộc generic | Yêu cầu tất cả tham số generic phải implement trait | Chỉ yêu cầu các kiểu dữ liệu field phải implement trait |
| Ví dụ về ràng buộc | T: Clone cho struct Wrapper<T>(Arc<T>) |
Arc<T>: Clone cho struct Wrapper<T>(Arc<T>) |
| Tác động Semver | Ổn định - ràng buộc không thay đổi khi sửa đổi field | Có thể gây breaking - ràng buộc thay đổi khi private field thay đổi |
| Độ phức tạp implementation | Đơn giản, có thể dự đoán | Yêu cầu hỗ trợ cyclical trait matching |
Những thách thức kỹ thuật đằng sau hậu trường
Cuộc thảo luận cho thấy đây không chỉ đơn giản là một sự sơ suất có thể được sửa chữa nhanh chóng. Theo những hiểu biết được chia sẻ trong cộng đồng, việc triển khai perfect derive sẽ yêu cầu những thay đổi đáng kể đối với hệ thống trait matching của Rust. Trình biên dịch sẽ cần xử lý trait matching theo chu kỳ, điều hiện tại chỉ hoạt động cho các auto trait như Send.
Cũng có một mối quan tâm về tương thích semver. Với perfect derive, việc thay đổi các kiểu field private có thể phá vỡ downstream code theo những cách không mong đợi. Nếu một thư viện thay đổi từ lưu trữ Arc<T> sang lưu trữ T trực tiếp, các trait bound sẽ tự động thay đổi, có thể gây ra lỗi biên dịch cho người dùng của thư viện đó.
Quan điểm của cộng đồng về các giải pháp
Cộng đồng Rust bị chia rẽ về cách giải quyết hạn chế này. Một số nhà phát triển lập luận để giữ hệ thống hiện tại đơn giản và có thể dự đoán được, xem các trait implementation thủ công như một chi phí có thể chấp nhận được để có sự rõ ràng. Những người khác thúc đẩy các giải pháp tinh vi hơn sẽ phân tích các yêu cầu field thực tế thay vì các ràng buộc tham số generic toàn diện.
Phần mềm thanh lịch được đo bằng số dòng code mà bạn không cần phải viết.
Một số thành viên cộng đồng đã chỉ ra các crate hiện có như derive_more, derivative, và educe như những giải pháp thực tế. Những giải pháp của bên thứ ba này đã triển khai hành vi derive thông minh hơn, mặc dù chúng thêm overhead dependency vào các dự án.
Các Giải Pháp Thay Thế Có Sẵn
- crate derive_more: Chức năng derive mở rộng với các ràng buộc linh hoạt hơn
- crate derivative: Cho phép kiểm soát chi tiết hành vi derive thông qua các thuộc tính
- crate educe: Cung cấp các triển khai derive có thể tùy chỉnh
- Triển khai thủ công: Viết các triển khai trait bằng tay khi derive không đủ
- Macro proc tùy chỉnh: Tạo các macro derive chuyên biệt cho dự án với hành vi mong muốn
Con đường phía trước
Trong khi một số người đề xuất điều này có thể được giải quyết thông qua một RFC và các thay đổi ngôn ngữ cuối cùng, timeline cho những sửa đổi như vậy có thể sẽ kéo dài vài năm do tính chất breaking của các thay đổi. Cuộc thảo luận cộng đồng làm nổi bật sự căng thẳng giữa tính ổn định của ngôn ngữ và sự tiện lợi cho nhà phát triển.
Hiện tại, các nhà phát triển tiếp tục dựa vào các implementation thủ công hoặc các crate của bên thứ ba khi họ gặp phải những hạn chế này. Cuộc tranh luận nhấn mạnh cách mà ngay cả những tính năng ngôn ngữ có vẻ đơn giản cũng có thể liên quan đến những đánh đổi thiết kế phức tạp ảnh hưởng đến cả khả năng sử dụng hiện tại và sự phát triển ngôn ngữ dài hạn.
Tham khảo: Why not?