[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Marc Mutz]

Guys, this thread is for QStringView. Could we keep it on-topic, please? There 
are more than enough bits floating around to create your own threads (with a 
tip of the hat to Kai).

Thanks,
Marc

On Thursday 15 October 2015 23:02:09 Bubke Marco wrote:
> On October 15, 2015 00:27:45 Thiago Macieira <thiago.macieira at intel.com> 
wrote:
> > On Wednesday 14 October 2015 21:51:23 Bubke Marco wrote:
> >> On October 14, 2015 23:10:26 Thiago Macieira <thiago.macieira at intel.com>
> > 
> > wrote:
> >> > Do it on your own. You just said that ICU has the function you want,
> >> > so use
> >> > it.
> >> 
> >> So Qt is always shipping with ICU?
> > 
> > It can be disabled on Windows. On OS X there's no point since it's part
> > of the system. On Linux, if you disable it, you're going to have some
> > other features reduced, so don't disable it.
> > 
> >> > Qt does not have to provide a comparator that operates on something
> >> > other than its native string type.
> >> 
> >> Isn't Qt a framework to help developers? Sorry your argumentation is
> >> sounds not very empirical.
> > 
> > Yes, it is. But Qt's goal is not to support every single use-case and
> > corner- case out there. Qt should make 90% easy and 9% possible. That
> > means there's a 1% of the realm of possibilities that Qt does not
> > address. If your use-case calls into this group, use the fact that Qt is
> > native code and just call other libraries.
> 
> Actually I think Qt is not main developing library people use. It is there
> to make the boring stuff easy, to hide the different interfaces between
> different platforms. That is why many people use Qt,  they want to have a
> GUI but don't want to invest to much time in it. The interesting stuff 
> which is differentiating you from others is mostly home grown in
> connection with much more specialized libraries. And this libraries are
> much more important to the users. So we should support them, their
> interfaces and not force our interfaces on them. How many users use the
> standard library too,  especially the new features, why don't we support
> them not much better. Why do we have to reinvent the wheel again and
> again. I know binary compatibility is important for you but is it really
> that important outside of the special linux distribution cocoon. Is it
> important under Windows,  is it important under Mac, is it important under
> embedded Linux? I think the advantages are smaller than the drawbacks.
> 
> > That's one of the two main advantages of native code. There's no sandbox
> > to escape from.
> > 
> > Qt already supports doing locale-aware comparison. We even have a class
> > for it, so it can be done efficiently: QCollator and it supports our
> > native string type (QString).
> 
> Do you like to live on a native island?
> 
> > Providing extra support for a character encoding that is not what QString
> > uses falls in that 1%. Just use ICU.
> 
> You arguments sounds very tautological. Because it is unimportant we don't
> have it a string class for it. It is unimportant because QString is not
> supporting it.
> 
> I know you love plationian argumentation but it would be much more
> effective if you would try to get in the context of other and understand
> their arguments in their context.  Showing in your own context that their
> arguments "makes no sense" is not very useful.
> 
> >> Lets describe an example. I send the QTextDocument content to an library
> >> which expect utf8 content and gives me back positions. This gets
> >> interesting if you use non ASCII signs. Actually the new clang code
> >> model works that way.
> > 
> > That example shows how UTF-16 is better. See above on seekability of
> > UTF-16 vs UTF-8.
> > 
> > The solution for this is to fix the library to accept UTF-16. When we
> > were doing Qt 5.0, we needed PCRE to support UTF-16. Their developers
> > were very welcoming and wrote the version that supports UTF-16, so Qt
> > does not need to reallocate.
> 
> You have ever heard of Pippi Longstocking: "Widdiwiddiwitt, we make the
> world like we wish it should be. "  or how it is translated to english.
> You really think that you can force other larger projects to use utf16
> instead of utf8 if it has disadvantages for them.
> 
> And the PCRE is now supporting both at  runtime? Especially for large text
> it would be very helpful if you don't need to convert them to QString
> before you use  regular expressions on it.
> 
> >> > Even if we provide UTF-8 support classes, those will not propagate to
> >> > the GUI. Forget it.
> >> 
> >> What about compressing UTF 16 like python is doing it for UTF 32. If you
> >> are only using ascii you set a flag and you can remove all that useless
> >> zeros. It would be have implications for data() but maybe we should not
> >> provide access to the internal representation. If you use UTF 32 as a
> >> base you don't need anymore surrogates.
> > 
> > That's what Lars called a "hybrid solution" and vetoed. I second that.
> > 
> > Way too much code would break if we did that because we allow people
> > access to the data pointer in QString and to iterate directly
> > (std::{,w,u16}string don't allow that, which makes parsing them actually
> > a lot more cumbersome).
> 
> I don't see the disadvantage if you have special iterators. That is the
> power of iterators and with the new features of C++ they get really
> useful. But anyway,  I don't say that we have to change everything. The
> last time we did that we broke our event system which is still not working
> like it was before we introduced QWindow. I think we  should have an
> evolutionary process to  adapt to the  changing environment and not try to
> reiterate what was successful in the past.
> 
> And we should memory why we have done things and if that decision would be
> the same today. And in the end we have to decide if it is worth to change
> that decision again. _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts