title: Rust "Borrowed pointers" syntax
body: <p>Reading the <a href="http://static.rust-lang.org/doc/master/guide-lifetimes.html" rel="nofollow">rust tutorial</a> managed and owned pointers can be passed to a function requiring borrowed pointers as-is and are converted to borrowed pointers at compile time.</p>
  
  <p>Why can't the stack variable be passed in the same way? What syntax or feature requires the explicit <code>&amp;</code> operator to pass that one as opposed to the compiler automatically converting it?</p>
  
  <pre><code>struct Point {x: float, y: float}
  
  let on_the_stack :  Point =  Point {x: 3.0, y: 4.0};
  let managed_box  : @Point = @Point {x: 5.0, y: 1.0};
  let owned_box    : ~Point = ~Point {x: 7.0, y: 9.0};
  
  fn compute_distance(p1: &amp;Point, p2: &amp;Point) -&gt; float {
      let x_d = p1.x - p2.x;
      let y_d = p1.y - p2.y;
      sqrt(x_d * x_d + y_d * y_d)
  }
  
  compute_distance(&amp;on_the_stack, managed_box);
  compute_distance(managed_box, owned_box);
  </code></pre>
  
  <p>Adding to the confusion is a quote from kibwen on ycombinator (I can't find the original quote but here's the quote of the quote)</p>
  
  <blockquote>
    <p>We’ll still have &amp; and &amp;mut, but those aren’t pointers, they’re references (it’s our own fault for calling them “borrowed pointers” in our documentation)</p>
  </blockquote>
  
  <p>If <code>compute_distance</code> is taking references and the compiler converts pointers to references automatically why can't it do the same for values?</p>
  
  <p><strong>Edit:</strong> Since pnkfelix seems to know what he's talking about I'll copy some dialogue here for easier reading.</p>
  
  <p>pnkfelix</p>
  
  <blockquote>
    <p>The designers of Rust decided to not follow the path of C++ in this respect. One side-effect of this decision is that when someone reading the code looks at an invocation like f(x, y) in Rust, one need not spend time wondering "wait, how does f take its arguments; if it mutates y, will I see that reflected in that after f returns? What about x?" etc.</p>
  </blockquote>
  
  <p>J V</p>
  
  <blockquote>
    <p>I may be confused on the nature of references then. <code>@var</code> and <code>~var</code> in rust are pointers (Though they do behave more like references) - are C++ references simply pointers under the hood?</p>
    
    <p>In any case, I could apply the same logic to C with regards to code readability.</p>
    
    <p>Variables are either values or pointers (Where you simply pass the variable as you do in rust: <code>f(var)</code>) or are referenced in the function call (like you do in rust: <code>f(&amp;var)</code>) - I would have thought the rust compiler would recognize the function signature and handle this automatically. I don't see the improvement over C or C++</p>
  </blockquote>
  
  <p>pnkfelix</p>
  
  <blockquote>
    <p>One followup: this line that I wrote: "wait, how does f take its arguments; if it mutates y, will I see that reflected in that after f returns? What about x?" is somewhat facetious, since even a call like f(&amp;x, y) would not be able to modify x; it would have to be f(&amp;mut x, y). (and the declaration of x itself would have to be let mut x = ..., etc. – pnkfelix 1 hour ago</p>
    
    <p>2nd followup: a reason why explicit &amp;x may be more important in Rust than in C/C++ (rather than letting f(x,y) implicitly do the borrow &amp;x), is because the borrow checker forces borrows to follow certain rules, and will refuse to compile code that does not conform. When you get an error from the borrow-checker, IMO it is a better user-experience if the compiler points to an expression of the form &amp;x or &amp;mut x in the source, rather that pointing to a function call and saying "there's an implicit borrow here." (That's subjective opinion, of course.) – pnkfelix 1 hour ago</p>
    
    <p>I saw that you had a follow-up note in your reply, but I don't understand the point you are making about applying "the same logic to C". If you mean C as opposed to C++, then you usually do have to explicitly take addresses of memory when invoking functions that expect pointers. If a function takes a <code>int**</code>, then someone needs to do <code>&amp;E</code> where <code>E</code> is an l-value of type <code>int*</code>. That seems analogous to Rust to me. (The main exception to this that I recall offhand from C is function-pointers; you don't need to do <code>&amp;f</code> to make a function pointer to <code>f</code>.) – pnkfelix 1 hour ago</p>
  </blockquote>
  
  <p>J V</p>
  
  <blockquote>
    <p><em>That seems analogous to Rust to me.</em> - exactly my point - from a readability point of view there's not much of an improvement over plain C. <em>because the borrow checker forces borrows to follow certain rules...rather that pointing to a function call and saying "there's an implicit borrow here."</em> Bingo - this is one of the underlying reasons I was looking for. If you find any other reasons for the manual cast feel free to add to your answer!</p>
  </blockquote>