]> git.lizzy.rs Git - rust.git/commitdiff
Remove rule that is confusing
authorBrandon Waskiewicz <brandon.waskiewicz@gmail.com>
Thu, 17 Apr 2014 20:59:58 +0000 (16:59 -0400)
committerBrandon Waskiewicz <brandon.waskiewicz@gmail.com>
Thu, 17 Apr 2014 20:59:58 +0000 (16:59 -0400)
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').

src/doc/guide-pointers.md

index 5c6c562b72d37a5d36456a60145e8fa023110c77..9780a12a4028ee4185fdaf9812bfe9481dac989e 100644 (file)
@@ -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: