[Development] Making QScopedPointer scoped (again)

[Simon Hausmann]

On Tuesday 3. September 2013 10.02.52 Stephen Kelly wrote:
> Hi there,
> 
> Commit 5b9006bbdba7dcab01b8e640554a7d7a4b64f76b in qtbase added move
> capability to QScopedPointer.
> 
> That means that in Qt 5.2, if you use C++11, you can do this:
> 
>  int main(int argc, char **argv)
>  {
>    QScopedPointer<int> p_out;
>    {
>      QScopedPointer<int> p(new int);
>      p_out = std::move(p);
>    }
>  }
> 
> However, if you want to move a QScopedPointer like that, then you don't want
> a QScopedPointer at all, but a std::unique_ptr instead.
> 
> It also means that you can put a QScopedPointer in your API:
> 
>  QScopedPointer<int> returnScopedPointer()
>  {
>    QScopedPointer<int> p(new int);
>    return p;
>  }
> 
>  int main(int argc, char **argv)
>  {
>    QScopedPointer<int> p = returnScopedPointer();
>  }
> 
> 
> Again, this is what std::unique_ptr is for. We should not try to turn
> QScopedPointer into an attempt at a NIH std::unique_ptr. Where people have a
> need for a std::unique_ptr, they should use it. We should not adapt
> QScopedPointer to fit the need instead.
> 
> Adding a move contructor to QScopedPointer makes no sense, because moving
> means 'escaping the scope', which breaks the fundamental point of
> QScopedPointer. QScopedPointer is different to std::unique_ptr and should
> remain so.

The only argument I can see in your email that explains _why_ this feature 
shouldn't be added to QScopedPointer is NIH.

What is the price of NIH here? Compared to the value we're adding at the same 
time to developers who are not able to rely on C++11 yet?

Qt's goal is to make life easier for developers. Adding a small piece of 
functionality to QScopedPointer seems to be in line with that goal IMHO.


Simon