[Development] RFC: Deprecating setSharable / isSharable in our containers and QString

[Tony Van Eerd]

> 
> I agree on detach(): you can easily trigger a detach() by calling data().
> Well, as long as you ensure that your object is not const.
> 

I wouldn't get rid of detach() just because data() can do the same thing.  If it is useful, I'd rather use the proper name for it.
The question is whether it is useful...

> But we can't remove it because it's used by everything that does detaching.
> For example:
> 
> 	T *data() { detach(); return d->data(); }
> 

... for *public* use.  It obvious it useful as a private function.

> 
> As for isDetached(), I have a use for it right now:
> 
> QByteArray QString::toLatin1_helper_inplace(QString &s) {
>     if (!s.isDetached())
>         return s.toLatin1();
> 
>     // We can return our own buffer to the caller.
>     // Conversion to Latin-1 always shrinks the buffer by half.
>     const ushort *data = reinterpret_cast<const ushort *>(s.constData());
>     uint length = s.size();
> 
>     // Swap the d pointers.
>     // Kids, avert your eyes. Don't try this at home.
>     [...]
> }
> 

That's also private use.  So detach() and isDetached() could be private functions.

The (philosophical) question is "If it is useful privately, might it also be useful publicly? If so, why keep the power away from clients?"
(And there are various answers to each of those questions, in general.)

Tony