5 ms·

I can't wait to see improved borrow checking! I'm not sure it'll fix this specific case, but I often find myself needing to introduce a scope just to hint the b

I can't wait to see improved borrow checking! I'm not sure it'll fix this specific case, but I often find myself needing to introduce a scope just to hint the borrow checker into doing the right thing. For example: fn handle_message(&mut self, find_node_query: messages::FindNodeQuery) { let origin = node::UdpNode::deserialize(find_node_query.get_origin()); let target = Address::from_str(find_node_query.get_target()); { // Borrow self.routing_table first time let nodes: Vec<&Box<node::Node>> = self.routing_table.nearest_to(&target); let response = Message::Response( self.transaction_ids.generate(), Response::FindNode(&self.self_node, nodes)); origin.send(response.serialize()); } // Done borrowing self.routing_table here // Borrow self.routing_table again self.routing_table.insert(origin); } edit: upon digging into the details, it looks like it may: https://github.com/rust-lang/rfcs/blob/db66dd2039b10b759084079827d85aba1c26256c/active/0000-seme-regions.md https://github.com/rust-lang/rfcs/blob/db66dd2039b10b7590840...

steveklabnik 11y ago
Yes, this is "non-lexical borrows"/"SEME regions", and is exactly what MIR will enable. Or at least, is one of the things :)
- Shoop 11y ago
  Could we see non-lexical borrows within the year?
  - deleted 11y ago
    [deleted]
  - steveklabnik 11y ago
    I'm not sure I can say for sure when they'll be ready, as MIR isn't 100% done, and they're built on top, so it's tough. There's also the difference between "lands in nightly" and "lands in stable", which could be some time for a feature so large.
  - kibwen 11y ago
    I think it's too early to say. The devs have assured me that MIR itself will land within the year, but beyond that point I think that non-lexical borrows might be out-prioritized (though just barely so) by incremental recompilation.
tychuz 11y ago
Every time I see rust news, I feel the urge to learn this language. But, thankfully, someone posts some random snippet. :-) Java is a beautiful language compared to this.
- Sacho 11y ago
  My only complaint is the mix between snake_case and PascalCase. I tried removing it(in favor of snake_case, but you could probably get a similar result if going full PascalCase), and it looks much better(no guarantee it has the same semantics, I've never worked with rust): fn handle_message(&mut self, find_node_query: messages::find_node_query) { let origin = node::udp_node::deserialize(find_node_query.get_origin()); let target = address::from_str(find_node_query.get_target()); { // Borrow self.routing_table first time let nodes: vec<&box<node::node>> = self.routing_table.nearest_to(&target); let response = message::response( self.transaction_ids.generate(), response::find_node(&self.self_node, nodes) ); origin.send(response.serialize()); } // Done borrowing self.routing_table here // Borrow self.routing_table again self.routing_table.insert(origin); }
  - pcwalton 11y ago
    Rust used to work that way, but it was changed primarily to visually distinguish between enumerated variant names and variable bindings in patterns. e.g. match foo { none => ... } and match foo { non => ... } having completely different interpretations was confusing.
  - kibwen 11y ago
    It sure does look more like C that way (if that's something you're into), but that also makes it harder to scan for types at a glance.
- dschiptsov 11y ago
  Exactly. There are few fundamental principles which have been neglected in order to provide way too many features (a kitchen sinc syndrome). For example, "do not create unecessary entities" maxim, which, it seems, is central for good language design (ML, Scheme, Haskell, Smalltalk, Erlang, Golang are small languages, the first three are even standardized). As long as we violate this genetal rule we end up in a mess like CL, C++, and of course Java as a peak of absurdity). The meme that "implementation languages must be feature rich" does not hold beyond certain limits, and even Rust designers have realized that there must be certain restrictions. In fact, C - the oldest and most common implementation language is still alive and well (despite all the mess other people made of it since it left Bell Labs). The best illustration I know is refusal of the Golang designers to complicate (to ruin the balance of simplicity and elegance with expressiveness, which is the most difficult to attain - every poet or artist will tell you that - to create an unbalanced pile of features is way easier) the language by adding generics in the language and runtime. For them interfaces (duck-typing) is good-enough). "Explicit is better than implicit" is also a naively wrong maxim. Verbosity is bad. Period. Every good writer I know is non-verbose. Meaning behind words is what makes a good literature, not long words or elaborate passages half page long (ironically, common men think exactly opposite is true). Convention over configuration (evolved defaults instead of explicitly spelling every single rule over and over again) is the same notion from a different perspective. Here comes Scheme - the greatest mostly-functional small language with balanced defaults, cohetent semantics (almost like in math), and unmatched expressiveness with almost no syntax at all (expressive power comes from coherent defaults that everything is an expression, everything (including lambdas) is a first-class value referenced by symbol, lexical scooping, very few standard special forms and the ability to create new ones.) as an good example. Smalltalk and Erlang are another ones for the emphasis on message passing and, in case of Erlang - pure functionality and isolation - the way vastly complex biological systems has been implemented by evolution. So, those who have seen highly refined languages like Haskell or Scheme or Smalltalk would never be fooled by "features". The meme that "each project must first agree on which subset of C++ it would restrict itself to" is another good illustration. Rust, like Java, is already suffering from this kitchen sink syndrome, so the comment above is legitimate. BTW, it seems that many of features should go from the language to sanitizers and checkers, like it is with clang tooling.

steveklabnik 11y ago

Yes, this is "non-lexical borrows"/"SEME regions", and is exactly what MIR will enable. Or at least, is one of the things :)

Shoop 11y ago
Could we see non-lexical borrows within the year?
- deleted 11y ago
  [deleted]
- steveklabnik 11y ago
  I'm not sure I can say for sure when they'll be ready, as MIR isn't 100% done, and they're built on top, so it's tough. There's also the difference between "lands in nightly" and "lands in stable", which could be some time for a feature so large.
- kibwen 11y ago
  I think it's too early to say. The devs have assured me that MIR itself will land within the year, but beyond that point I think that non-lexical borrows might be out-prioritized (though just barely so) by incremental recompilation.

tychuz 11y ago

Every time I see rust news, I feel the urge to learn this language. But, thankfully, someone posts some random snippet. :-) Java is a beautiful language compared to this.

Sacho 11y ago
My only complaint is the mix between snake_case and PascalCase. I tried removing it(in favor of snake_case, but you could probably get a similar result if going full PascalCase), and it looks much better(no guarantee it has the same semantics, I've never worked with rust): fn handle_message(&mut self, find_node_query: messages::find_node_query) { let origin = node::udp_node::deserialize(find_node_query.get_origin()); let target = address::from_str(find_node_query.get_target()); { // Borrow self.routing_table first time let nodes: vec<&box<node::node>> = self.routing_table.nearest_to(&target); let response = message::response( self.transaction_ids.generate(), response::find_node(&self.self_node, nodes) ); origin.send(response.serialize()); } // Done borrowing self.routing_table here // Borrow self.routing_table again self.routing_table.insert(origin); }
- pcwalton 11y ago
  Rust used to work that way, but it was changed primarily to visually distinguish between enumerated variant names and variable bindings in patterns. e.g. match foo { none => ... } and match foo { non => ... } having completely different interpretations was confusing.
- kibwen 11y ago
  It sure does look more like C that way (if that's something you're into), but that also makes it harder to scan for types at a glance.
dschiptsov 11y ago
Exactly. There are few fundamental principles which have been neglected in order to provide way too many features (a kitchen sinc syndrome). For example, "do not create unecessary entities" maxim, which, it seems, is central for good language design (ML, Scheme, Haskell, Smalltalk, Erlang, Golang are small languages, the first three are even standardized). As long as we violate this genetal rule we end up in a mess like CL, C++, and of course Java as a peak of absurdity). The meme that "implementation languages must be feature rich" does not hold beyond certain limits, and even Rust designers have realized that there must be certain restrictions. In fact, C - the oldest and most common implementation language is still alive and well (despite all the mess other people made of it since it left Bell Labs). The best illustration I know is refusal of the Golang designers to complicate (to ruin the balance of simplicity and elegance with expressiveness, which is the most difficult to attain - every poet or artist will tell you that - to create an unbalanced pile of features is way easier) the language by adding generics in the language and runtime. For them interfaces (duck-typing) is good-enough). "Explicit is better than implicit" is also a naively wrong maxim. Verbosity is bad. Period. Every good writer I know is non-verbose. Meaning behind words is what makes a good literature, not long words or elaborate passages half page long (ironically, common men think exactly opposite is true). Convention over configuration (evolved defaults instead of explicitly spelling every single rule over and over again) is the same notion from a different perspective. Here comes Scheme - the greatest mostly-functional small language with balanced defaults, cohetent semantics (almost like in math), and unmatched expressiveness with almost no syntax at all (expressive power comes from coherent defaults that everything is an expression, everything (including lambdas) is a first-class value referenced by symbol, lexical scooping, very few standard special forms and the ability to create new ones.) as an good example. Smalltalk and Erlang are another ones for the emphasis on message passing and, in case of Erlang - pure functionality and isolation - the way vastly complex biological systems has been implemented by evolution. So, those who have seen highly refined languages like Haskell or Scheme or Smalltalk would never be fooled by "features". The meme that "each project must first agree on which subset of C++ it would restrict itself to" is another good illustration. Rust, like Java, is already suffering from this kitchen sink syndrome, so the comment above is legitimate. BTW, it seems that many of features should go from the language to sanitizers and checkers, like it is with clang tooling.