The C++ Standard Library Deprecations

[H. S. Teoh]

On Sunday, 24 May 2026 at 07:45:51 UTC, Walter Bright wrote:
> https://hftuniversity.com/post/the-c-standard-library-has-been-walking-itself-back-for-fifteen-years-and-the-receipts-are-public
>
> This is a thorough discussion of C++ misfeatures in the 
> standard library, why they are wrong, and why they happened.
>
> It's very interesting reading, and has lessons for us in 
> Phobos2.


Very telling quote:

> This is not a critique of the committee's individual members,
> most of whom are doing the hardest possible job in the most
> thankless possible venue. It is a critique of the structural
> commitment to never break existing code, which means the slow
> containers, the broken regex, the deadlocking async, the 
> costless
> auto_ptr admission, the costless aligned_storage admission, all
> of it stays. The standard library is now a layer cake of fifteen
> years of "do not use that, use this instead", and the working
> engineer's job is to know the dates of the bad layers.

In the early days the official stance in D is "never break code", 
even when users actively begged "please break our code -- if it 
makes the language better".  IMO we should review this stance in 
light of C++'s experience.

//

A less dramatic takeaway that I got is that containers are very 
hard to design.  What seems like a good idea today is trumped by 
next year's new design.  Standardizing on containers leads to the 
C++ situation of standard containers being avoided because 
they're outdated by the time they're shipped.  D also suffers 
from the same problem: the standard Phobos containers, while IMO 
(somewhat) better than C++'s, are still substandard and leave a 
lot to be desired.  And users have been begging for standard 
containers for years, maybe even decades, and std.container has 
not changed significantly since I first starting using D.

Perhaps the better approach is to let containers be delegated to 
3rd party libraries.  Let the "market" figure out for itself 
what's best, and the best contenders become the de facto 
standard.  For interoperability, D could have official APIs (akin 
to the range API) that provide a baseline common denominator, but 
no more than that. Some things are better off not being in the 
standard library, much as we like D to come "with batteries 
included".

//

Another takeaway is what the author called the "Vasa problem": 
features that make sense in isolation, but in conjunction with 
the rest of the language causes the whole thing to be top-heavy 
with poor interaction with other features.  While C++ is 
notorious for this (cf. https://bartoszmilewski.com/2013/09/), D 
also has its fair share of features that totally make sense in 
isolation, but interact poorly with other features.

On this front I applaud the approach of making the first 
implementation of editions remove features rather than add them. 
Before installing yet another overwrought cannon on the Vasa, 
better first remove some of the stuff that in retrospect we 
didn't need after all.


--T