AUDULUS USER LIBRARY CODE
People of course say they like that this enforces a style on people so other people's code obeys their preferred rules. So I think it would be great if the user had the freedom to implement Copy as they want. But there are cases where you'd like to have ergonomics over performance. They should be designed with performance in mind. Now, I understand the point of standard library types not copying implicitly. I've also spoken with a rather prominent rust programmer who called it an "ergonomics paper cut." He wants to program in a very value-oriented FP style. I was just talking with a programmer I respect greatly, who used rust for a project but decided because of this behavior it felt "too low level" and went back to C++ (for new projects!). What I ended up doing was making those types Copy, which caused other ergonomics issues, but I decided the tradeoff was worth it. It took away from the declarative style.Īnnoying. In my UI library case there were more lines of cloning and things got a bit ugly. If a and b aren't Copy I've gotta clone them: let x = a.clone() Ok, fine, well what about this case: f(move || g(a, b)) I chalk it up to survivorship bias.Īnyway, suppose you wanted to make a NxM (dynamic) matrix type (like Eigen, say) and you want it to have good ergonomics, so x = y not x = y.clone(). Rust devotees seem to love this, so you don't need to tell me how much you do. The Copy trait is "Types whose values can be duplicated simply by copying bits." That is, an expression of the form x=y always denotes a bitwise copy and no allocation happens. So I recently had to compromise the ergonomics of my library ( GitHub - audulus/rui: Experimental Rust UI library) because Rust doesn't allow arbitrary code to be executed on assignment.
0 kommentar(er)
