Why Rust's ownership/borrowing is hard » комментарииhttp://softwaremaniacs.org/blog/2016/02/11/ownership-borrowing-hard/2017-05-13T10:37:32-07:00Иван Сагалаев о программировании и веб-разработкеhttp://softwaremaniacs.org/media/about/avatar.pngIvan Sagalaev на "Why Rust's ownership/borrowing is hard"
2017-05-13T10:37:32-07:00Ivan Sagalaevhttp://softwaremaniacs.org/blog/2016/02/11/ownership-borrowing-hard/#comment-494479I think your use of "diverged" in "Since in Rust definition of data fields (struct) is diverged from definition of methods (impl)" is not correct. I would use "divorced" or "separate". And you're missing "the" before both uses of "definition". But I know that's difficult for eastern-europeans. Fixed, thanks!
<blockquote>
<p>I think your use of "diverged" in "Since in Rust definition of data fields (struct) is diverged from definition of methods (impl)" is not correct. I would use "divorced" or "separate". And you're missing "the" before both uses of "definition". But I know that's difficult for eastern-europeans.</p>
</blockquote>
<p>Fixed, thanks!Jan на "Why Rust's ownership/borrowing is hard"
2017-03-26T08:57:32-07:00Janhttp://softwaremaniacs.org/blog/2016/02/11/ownership-borrowing-hard/#comment-494473I think your use of "diverged" in "Since in Rust definition of data fields (struct) is diverged from definition of methods (impl)" is not correct. I would use "divorced" or "separate". And you're missing "the" before both uses of "definition". But I know that's difficult for eastern-europeans. Note I'm not...
<p>I think your use of "diverged" in "Since in Rust definition of data fields (struct) is diverged from definition of methods (impl)" is not correct. I would use "divorced" or "separate". And you're missing "the" before both uses of "definition". But I know that's difficult for eastern-europeans.</p>
<p>Note I'm not a native English speaker either, so take this with a grain of salt.Jean-Pierre на "Why Rust's ownership/borrowing is hard"
2016-11-22T11:39:33-08:00Jean-Pierrehttp://softwaremaniacs.org/blog/2016/02/11/ownership-borrowing-hard/#comment-494460Seconding Martin here: this was very, very helpful.
<p>Seconding Martin here: this was very, very helpful.Ralf на "Why Rust's ownership/borrowing is hard"
2016-02-19T02:48:57-08:00Ralfhttp://softwaremaniacs.org/blog/2016/02/11/ownership-borrowing-hard/#comment-494432Rust's ownership/borrowing system is hard because it creates a whole new class of side effects. Notice however that what you call an "effect" here is actually very, very different from the "effects" people usually mean when they say "side-effect". All this business about ownership and moving is purely a compile-time...
<blockquote>
<p>Rust's ownership/borrowing system is hard because it creates a whole new class of side effects.</p>
</blockquote>
<p>Notice however that what you call an "effect" here is actually <em>very, very different</em> from the "effects" people usually mean when they say "side-effect". All this business about ownership and moving is purely a compile-time notion, it does not change at all what your code does. Hence it doesn't make reasoning about your code's behavior any harder, since the behavior is not changed. Actually, it makes that reasoning much simpler (provided the program passes the borrow checker) because the side-effects are now much more controlled.</p>
<p>So, maybe it helps to think about the borrow checker like that: As you said, reasoning about effects is hard. This applies in particular to reasoning about <em>unrestricted</em> effects like C++ has them, where there could be aliases to all sorts of data pretty much everywhere. This can get hard to keep an overview of (just think of how many programs out there will use a pointer into a <code>std::vector</code> that has since then grown or shrunken). The borrowing and ownership business is not a new side effect, it is about restricting the existing side-effects: If you <em>own</em> something or have a <em>mutable reference</em> (which is necessarily unique), you know there are no surprising (non-local) side-effects to this object because nobody else can have an alias. By this I mean that calling some function on some other data will never, magically, mutate the data you own. If you have a shared reference, you know there are no side-effects because nobody is allowed to perform mutation of the data. (With the exception of interior mutability, which allows mutation in very controlled circumstances - with <code>RefCell</code>, you can pretty much end up in the same mess of uncontrolled side-effects as with C++, but at least there is run-time checking.)</p>
<p>When the compiler tells you that data is moved and you cannot use it, that's not a new side-effect. That's "just" the compiler understanding the side-effects we all know about, so that it can make sure they are kept under control. In C++, if you pass the <code>Point</code> above to some other function, the compiler makes a shallow copy, and if <code>Point</code> contains pointers, that can result in a mess. Now, <code>Point</code> in particular is safe to copy around, but you have to be explicit here and tell the compiler that you want it to be treated as such:</p>
<p><code>#[derive(Copy,Clone)] struct Point { ... }</code></p>
<p>You may wonder why the compiler does not figure this out automatically. It could, just like it does for <code>Send</code>. The problem here is interface stability: If you write a library that exports a type that just happens to be <code>Copy</code>, then the library is bound to always keep this type <code>Copy</code> in the future. It should be a conscious choice of the library author to guarantee that this type is and always will be <code>Copy</code>, hence the explicit annotation.Juarez на "Why Rust's ownership/borrowing is hard"
2016-02-16T03:19:53-08:00Juarezhttp://softwaremaniacs.org/blog/2016/02/11/ownership-borrowing-hard/#comment-494431I have the impression that Rust is adding a unnecessary complexity adopting "move by default" for non raw types. The programmer have the extra burden of 'boxing' references everywhere. In my view, seems natural to think of: a) 'copy by default' for raw types b) 'reference by default' for complex...
<p>I have the impression that Rust is adding a unnecessary complexity adopting "move by default" for non raw types.
The programmer have the extra burden of 'boxing' references everywhere.
In my view, seems natural to think of:
a) 'copy by default' for raw types
b) 'reference by default' for complex types (structs, traits, etc...) in synchronous methods
c) 'move by default' for complex types in asynchronous methods, and case by case.
What I am missing?Ivan Sagalaev на "Why Rust's ownership/borrowing is hard"
2016-02-13T15:49:08-08:00Ivan Sagalaevhttp://softwaremaniacs.org/blog/2016/02/11/ownership-borrowing-hard/#comment-494429Did you mean for the original version of next() to return a lexeme? The original version of Lexer::next() is not shown and Parser::next() actually returns parser events. I just fixed this bit, thanks!
<blockquote>
<p>Did you mean for the original version of next() to return a lexeme?</p>
</blockquote>
<p>The original version of <code>Lexer::next()</code> is not shown and <code>Parser::next()</code> actually returns parser events. I just fixed this bit, thanks!Jack O&#39;Connor на "Why Rust's ownership/borrowing is hard"
2016-02-13T09:40:23-08:00Jack O'Connorhttp://softwaremaniacs.org/blog/2016/02/11/ownership-borrowing-hard/#comment-494428Did you mean for the original version of next() to return a lexeme? It looks like you might've?
<p>Did you mean for the original version of next() to return a lexeme? It looks like you might've?Chris Winn на "Why Rust's ownership/borrowing is hard"
2016-02-13T00:15:58-08:00Chris Winnhttp://softwaremaniacs.org/blog/2016/02/11/ownership-borrowing-hard/#comment-494427For what it's worth, I never once thought you were anything but a native English speaker. Nice post.
<p>For what it's worth, I never once thought you were anything but a native English speaker. Nice post. Martin на "Why Rust's ownership/borrowing is hard"
2016-02-12T11:27:54-08:00Martinhttp://softwaremaniacs.org/blog/2016/02/11/ownership-borrowing-hard/#comment-494426Thank you so much for writing this! I've banged my head against this wall several times without finding a good solution!
<p>Thank you so much for writing this! I've banged my head against this wall several times without finding a good solution!