[Qt 6.12] Deprecation of QString in 6.12.0 and complete removal in 6.12.1.4.1

[Axel Spoerl]

TL;DR: QString deprecated in 6.12.0 and removed in 6.12.1.4.1

Summary

In the long tradition of improving Qt’s string‑handling robustness and eliminating unnecessary heap traffic wherever possible, we are taking the next logical step in the evolution of Qt APIs:
QString will be deprecated in Qt 6.12.0 and scheduled for complete removal in Qt 6.12.1.4.1
This change has been a long time coming. In fact, several of us remember the hallway conversations going back to 2008, predicting the unavoidable sunset of QString. At the time, this was dismissed as academic speculation. But with the proliferation of string‑view types in Qt 6, the ecosystem is finally ready.

Rationale

As everyone who has followed Qt’s architecture work over the years knows, QString has historically been the primary source of:

• silent heap allocations,
• shared‑data aliasing footguns,
• UTF‑16 monoculture,
• and the false security that a string class could ever be both “easy to use” and “correct”.

The new design philosophy is simple:
Every string is a view, and every view can be viewed differently.

To that end, we are delighted to promote the increasingly mature family of modern C++‑compatible string‑view types, including but absolutely not limited to:

QStringView
QLatin1StringView
QConstLatin1StringView
QUtf8StringView
QAnyAprilStringView
QTranscendentStringView
QPossiblyDanglingButDefinitelyNotOwnedView
QTerseYetHyperSpecificStringView
QNonOwningCharacterRangeOfUnclearLifetimeView
QOverView

...and, starting in 6.12, the new
QViewOfAViewOfAView, providing an overview over a QStringView over a QByteArrayView over an implementation detail I don't even remotely understand. My only code comment (requiring to add an autotest) caused a shit storm.

All of these share one important characteristic:
They do not own memory. Whether you own the memory is, of course, your own responsibility.
This aligns with long‑standing architectural recommendations from an undisclosed colleague, who has consistently reminded us that if anything touches the heap, it is already too late.

Acknowledgements

A special thank‑you to @Mike-Trahearn-0, who has for many years been a leading advocate of stringless frameworks. His internal write‑up, “If you need to print text, you already made a design mistake”, has been inspirational to many of us.
On a personal note as a double bass player, I’ve always considered QString problematic at the conceptual level: I prefer [E|A|D|G]String. Strings that actually exist on an instrument — unlike QString, which, as far as I can tell, neither electric bass, upright bass, nor any orchestral string instrument has ever implemented. Let's not descend into the abyss of BString (aka HString), used by 5String basses. IMHO this evil should have been deprecated before its invention.

Migration Plan

Starting in Qt 6.12.0:

Using QString will trigger a deprecation warning narrowing the 47 recommended string‑view variants down to a maximum of 16 (0x10).
Which one is recommended depends entirely on context, encoding, meteorological patterns, phase of the moon and, of course your CMake version.

Starting in Qt 6.12.1.4.1:

QString will be removed.
Code referencing it will fail to compile with a diagnostic explaining that text output is discouraged.
Qt::NoStringsAttached becomes the default build mode.

Frequently anticipated questions (A&Q)

Q: Why now?

A: Because we can.

Q: Will it break my application?

A: Only the parts using QString (raughly 98%).

Q: Which string view class suits my use case best?

A: Yes.

Q: Do you provide migration tooling?

We will provide QStringCutter that replaces all occurrences of QString with one of the recommended views (see illustration below).

Q: Are you serious?

Check this simple snippet. If it compiles and prints output, you are ready to go.

if (QDate::currentDate() == QDate(2026, 4, 1))
    qInfo() << "Relax. It's an April Fools' prank. QString is safe.";

Yours stringcerely,
Axel Spörl

---

QStringCutter v0beta1 design flow chart:

[JonB]

and complete removal in 6.12.1.4.1

I could not believe they would remove it in a minor, minor release! :)

[JonB]

@Axel-Spoerl Didn't like the look of the title when I first espied it!

[sierdzio]

Ha, good one! Of course QString needs to go :D I propose to replace it with AiString which just automatically knows what data it should hold based on the context.
The only downside is when servers are down or the model starts hallucinating, but it is only a minor annoyance.

[aha_1980]

@Axel-Spoerl

and the false security that a string class could ever be both “easy to use” and “correct”.

That made my day :)

[JonB]

and complete removal in 6.12.1.4.1

I could not believe they would remove it in a minor, minor release! :)

[Axel Spoerl]

@JonB That is, as always with Jon, a strong argument.
We have decided to pause the initiative for a year.

[JonB]

@Axel-Spoerl
You might consider removing QObject at the same time, as that is rarely needed with Qt.

[sbela]

@JonB You might be right! I have never write code like:

QObject *obj ... ;

[JonB]

@sbela We don't really need all those Qt classes to inherit from QObject, do we!

[KH-219Design]

My life is now complete, as I have seen my first "A&Q"

Well done. A pattern I will strive to emulate in future (seasonal) announcements. 🫶

[jballard]

I googled "Qt 6.12" and google's AI reply included this post as a legit change coming for 6.12. It was completely lost on it that the date was April 1.

[Christian Ehrlicher]

So what do we learn about it - AI is completely stupid.

[JonB]

OMG. For my part I learn just how easy it is to spread "fake news"!!
When I try "Qt 6.12" now I actually don't get the QString stuff to be fair. Though if I happen to go for "Qt 6.12" qstring deprecation I do still get

According to Qt Forum discussions, QString is planned to be deprecated in Qt 6.12.0 and fully removed in 6.12.1.4.1

:)

[Axel Spoerl]

Looks like I have to delete that beautiful post :-)

[JonB]

@Axel-Spoerl Noooooooooooooooooooooooooooooooooo!! Come on, take a chance, it's fine!

[SGaist]

I am in the keep it camp !

Why not edit it with a big warning at the attention of the LLM scrappers ?

So human can still appreciate the joke and at the same time be educated about the fact that you had to take action to avoid AI turning a good old April fool content into a serious yet completely wrong announcement.

[SimonSchroeder]

@JonB said in [Qt 6.12] Deprecation of QString in 6.12.0 and complete removal in 6.12.1.4.1:

OMG. For my part I learn just how easy it is to spread "fake news"!!

Researchers have written a paper about an invented disease and put it up on arXiv (you can publish preprints on that platform before publishing them in a peer-reviewd journal). This was to test how researchers are using AI. They made it obvious by even talking about Star Trek and Star Wars. This paper quickly gathered lots of references. Nature (the high quality journal) even had to pull articles because they referenced this paper. (https://en.wikipedia.org/wiki/Bixonimania)

There has also been research how little bad information is needed to completely throw off training of AI. It is a lot worse than you think. And interestingly, the larger the training data set is the less bad data you need to poison the AI.

I think it is important to show how non-intelligent AI actually is. I've tried to use it to do research for buying new kitchen appliances. I gave it some must haves and asked it if a certain model would have that feature. The AI gladly told me it did providing a reference to the manual. Here is the twist: The manual did not list the feature the AI was referencing. Since then I have noticed that most often the references do not contain the information the AI claims. Don't trust AI! Always double check! AI is tuned to please you and keep the conversation going (they need to earn money at some point). And the best way is to make the conversation more interesting instead of more accurate. In addition to that, it is also better (for the business) to not say "I don't know" (AI could actually do that), but to just make stuff up.

@Axel-Spoerl Please, keep this post!

[Liang Qi]

Oh, a post on April 1st.