From 58ae1e7c625491e9eceebdc9120ff009361106fa Mon Sep 17 00:00:00 2001 From: Brandon Waskiewicz Date: Thu, 17 Apr 2014 16:59:58 -0400 Subject: [PATCH] Remove rule that is confusing 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 | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/doc/guide-pointers.md b/src/doc/guide-pointers.md index 5c6c562b72d..9780a12a402 100644 --- a/src/doc/guide-pointers.md +++ b/src/doc/guide-pointers.md @@ -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: