www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The C++ Standard Library Deprecations

reply Walter Bright <newshound2 digitalmars.com> writes:
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.
May 24
next sibling parent reply H. S. Teoh <hsteoh qfbox.info> writes:
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
May 25
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On the other hand, I find creating containers to be very easy work. I only add 
abilities to them that I actually need, so those containers tend to be spare, 
direct, and easy to understand.
Jun 05
next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Fri, Jun 05, 2026 at 07:12:53PM -0700, Walter Bright via Digitalmars-d wrote:

 On the other hand, I find creating containers to be very easy work. I
 only add abilities to them that I actually need, so those containers
 tend to be spare, direct, and easy to understand.


And that's precisely the problem.  Containers are simple when they're
specifically tailored for your specific use case.  Containers in a
standard library, though, need to be relevant to the general userbase;
and as we know, every one has their own exceptional corner case that
they expect should be supported. So standard library containers tend to
grow hairs over time and become anything but simple.


T

-- 
Famous last words: I *think* this will work...
Jun 05
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/5/2026 8:08 PM, H. S. Teoh wrote:

 And that's precisely the problem.  Containers are simple when they're
 specifically tailored for your specific use case.  Containers in a
 standard library, though, need to be relevant to the general userbase;
 and as we know, every one has their own exceptional corner case that
 they expect should be supported. So standard library containers tend to
 grow hairs over time and become anything but simple.


What I've been learning in trying to convert dmd's backend from lists to arrays 
is that the important thing is to have the same interface for both. Having a 
substantially different interface makes it very hard to try a different
container.
Jun 07
prev sibling parent Kagamin <spam here.lot> writes:
On Saturday, 6 June 2026 at 02:12:53 UTC, Walter Bright wrote:

 On the other hand, I find creating containers to be very easy 
 work.


Can confirm, dynamic array is 50 lines of code. Interoperability 
in C++ should be achieved by `string_view` and `span` interfaces, 
then the actual container doesn't matter.
Jun 15
prev sibling parent reply Jon Degenhardt <jondegenhardt nowhere.com> writes:
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.


It is an interesting read. A specific I found disconcerting is 
that I couldn't figure out who wrote it. Did I miss the 
authorship reference? A post like this shouldn't be anonymous.

--Jon
Jun 05
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/5/2026 8:43 AM, Jon Degenhardt wrote:

 It is an interesting read. A specific I found disconcerting is that I couldn't 
 figure out who wrote it. Did I miss the authorship reference? A post like this 
 shouldn't be anonymous.



I think it's AI generated.
Jun 05
parent Jon Degenhardt <jondegenhardt nowhere.com> writes:
On Saturday, 6 June 2026 at 01:58:42 UTC, Walter Bright wrote:

 On 6/5/2026 8:43 AM, Jon Degenhardt wrote:

 It is an interesting read. A specific I found disconcerting is 
 that I couldn't figure out who wrote it. Did I miss the 
 authorship reference? A post like this shouldn't be anonymous.



 I think it's AI generated.


Likely. But it should still be attributed, especially as it is an 
opinionated post. Including context provided to the AI. For 
example, was the AI asked to provide an objective analysis? Or 
was it asked to create a post critical of C++ backward 
compatibility goals?

I'm not arguing that the post is wrong. Just that such 
information should be provided. My academic side also tells me to 
be circumspect when following up on such posts.

--Jon
Jun 06