Skip to content

Commit

Permalink
auto merge of #13585 : brandonw/rust/patch-1, r=cmr
Browse files Browse the repository at this point in the history
The original text stated that one should only return a unique or managed pointer if you were given one in the first place. This makes it sound as if the function *should* return a unique pointer if it were given a unique pointer. The rest of the section goes on to describe why this is bad, and the example of bad code does exactly what the rule just said to do.

I reworded the original rule into a reference to the more concise rule mentioned at the bottom of the section, which helps add emphasis (a la 'it bears repeating').
  • Loading branch information
bors committed Apr 18, 2014
2 parents d35804e + 58ae1e7 commit ce2bab6
Showing 1 changed file with 3 additions and 2 deletions.
5 changes: 3 additions & 2 deletions src/doc/guide-pointers.md
Expand Up @@ -430,8 +430,9 @@ great detail, so if you want the full details, check that out.
# Returning Pointers

We've talked a lot about functions that accept various kinds of pointers, but
what about returning them? Here's the rule of thumb: only return a unique or
managed pointer if you were given one in the first place.
what about returning them? In general, it is better to let the caller decide
how to use a function's output, instead of assuming a certain type of pointer
is best.

What does that mean? Don't do this:

Expand Down

0 comments on commit ce2bab6

Please sign in to comment.