Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c++
Subject: Re: We have a new standard!
Date: Mon, 30 Dec 2024 13:25:44 +0200
Organization: A noiseless patient Spider
Lines: 95
Message-ID: <20241230132544.00005f92@yahoo.com>
References: <C++-20241227154547@ram.dialup.fu-berlin.de>
	<cone.1735354270.316807.177566.1000@ripper.email-scan.com>
	<vkojb7$96o6$1@dont-email.me>
	<vkp50p$ce10$1@dont-email.me>
	<vkr4ve$sksr$1@dont-email.me>
	<vkrk4l$10d4e$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Injection-Date: Mon, 30 Dec 2024 12:25:45 +0100 (CET)
Injection-Info: dont-email.me; posting-host="9e1d5ed9ca81ff929df9a5cd65273427";
	logging-data="1011330"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18hex5GZWqITlnpctclLuZKMKCE7KaTM3w="
Cancel-Lock: sha1:E5GsppEiZo3p02w03TVQGnJHS+Y=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)

On Sun, 29 Dec 2024 14:51:17 +0100
David Brown <david.brown@hesbynett.no> wrote:

> On 29/12/2024 10:32, Muttley@dastardlyhq.com wrote:
> > On Sat, 28 Dec 2024 16:20:57 +0100
> > David Brown <david.brown@hesbynett.no> gabbled: =20
> >> On 28/12/2024 11:19, Muttley@dastardlyhq.com wrote: =20
> >>> Being serious, I haven't even checked whats new in it but going
> >>> by C++ 2020
> >>> it'll be yet more syntactic soup to support features absolutely
> >>> no one outside
> >>> of ivory tower academic discussions asked for. It'll just add yet=20
> >>> morecomplexity to compilers, hence more potential bugs and make
> >>> the C++ learning
> >>> curve even steeper meaning yet more new programmers abandon it -
> >>> or don't
> >>> even start - for languages such as Python.
> >>> =20
> >>
> >> Ah, yes - the classic well-reasoned argument.=A0 Why would one ever
> >> want to /look/ at the new standard before condemning it? =20
> >=20
> > Ah yes, the same logic that has produced cars with ever more,
> > harder to use complexity that no one wants. =20
>=20
> No, not remotely.  But then, you knew that before making what you=20
> mistakenly thought was a smart or witty reply.
>=20
> If you don't like the complexity of newer C++ standards, that's fine.=20
> If you don't think it is a good direction for the language, fair
> enough. You can choose a different language, or stick to an older
> standard, or make your own language, or get involved in the C++
> standardisation processes and try to influence them.
>=20
> You can have an informed opinion about C++, and agree or disagree
> with the opinions of the committee members.
>=20
> But what you don't get to do - or at least, don't get to do if you
> want to be viewed seriously - is spout an /uninformed/ opinion.
> That's no more than mindless prejudice, and of no interest to anyone.
>=20
> So go away, and read about C++23.  Learn what is new or changed.
> /Then/ you can come back and tell us what you don't like about it -
> or perhaps you'll find some things that you /do/ like about it.
> Either way, you'll be at least vaguely qualified to express an
> opinion on it.
>=20
> <https://en.wikipedia.org/wiki/C%2B%2B23>
>=20

Comments after cursory view:

C++20 introduces two promising language features - concepts and
coroutines. Both were introduces without proper support in standard
library. Absence of support in library in both cases was justified by
probably correct claim that the best library constructs are still in
research state, non-crystallized. The hope was that universal
availability of this features at compiler level will help to best
library constructs to mature.

In case of coroutines developers were left with choice of 3 options:
1. To write a lot of boiler-plate code each time they a going to use
coroutines.
2. To try to organize repetitive patterns in the library (likely
template library) of their own and reuse it between parts of the
programs and multiple projects. Hopefully, share with community.
Hopefully, under liberal license.
3. Don't use coroutines

In case of concepts, the choice was even narrower:
1. Use concepts when you occasionally are writing container-like or
algorithm-like template of your own.
2. Don't use concepts.

Nobody was realistically expecting that grassroots developers will use
concepts to develop comprehensive widely reusable library that
duplicates functionality of STL, but brings advantage of sane error
messages.


So, where we are 3 years later?
W.r.t. concepts, in the same unfortunate place.
W.r.t. coroutines, library provides std::generator. I didn't look at it
yet. Hopefully, it works. Hopefully it is easy to use. But it is just
one of many possible uses of coroutines, and I would think that
it is not the one that could be considered most common.


Did I miss something?