3 ms·
Don't get wrong, rust looks fascinating. I realize that the syntax is basically sugar, but from what I understand is that you are still adding a method to a typ
by jimmyhmiller 13y ago
Don't get wrong, rust looks fascinating. I realize that the syntax is basically sugar, but from what I understand is that you are still adding a method to a type. Here's a snippet from the code.
fn days(&self) -> TimeChange {
TimeChange::new().days(*self as f32)
}
So while you are right, it is basically sugar for days(2).from_now(), but you couldn't call the function that way. It must be attached to an instance of an uint.
Also in order to get the English looking version you have to implement those function specially using traits. Whereas with the clojure version they are just normal functions, but the threading macro gives you that English readability you are looking for.
- wycats 13y agoYep! Those differences are totally correct. There are tradeoffs in each approach. One of the benefits of the Rust approach is that you can have a different implementation for each type (polymorphism), which is a feature I needed last week in some Rust code I wrote. FWIW: I believe that the Rust folks want to allow support for calling the functions directly.
- pcwalton 13y ago> So while you are right, it is basically sugar for days(2).from_now(), but you couldn't call the function that way. It must be attached to an instance of an uint. We plan to implement that, it's just not implemented yet: http://www.reddit.com/r/rust/comments/14pucx/rfc_method_call_syntax_as_sugar/ http://www.reddit.com/r/rust/comments/14pucx/rfc_method_call... > Whereas with the clojure version they are just normal functions, but the threading macro gives you that English readability you are looking for. You could do that with a macro in Rust as well. We don't make ordinary functions acquire that sugar for namespacing reasons: you can have multiple methods called e.g. "get" in scope as long as they're attached to different types, but that isn't true for functions.