

Where will Evolution lead C++17? - meetingcpp
http://meetingcpp.com/index.php/br/items/where-will-evolution-lead-cpp17.html

======
steven2012
Let me state for the record that Change is Good. C++ changing with the times
is really what is keeping it alive as opposed to the other legacy type
languages that have stagnated.

However, in my opinion C++ is changing too much, too quickly. I barely got the
changes from 2008 down pat, and I look up and not only have I missed the 2011
changes, but also the 2014 changes to digest. It's going too far too fast and
it feels like C++ steering committee is filled with ultra-experts that don't
understand that the young kids aren't picking up C++ because Python, Java,
Scala, etc are more digestible, and the older people like me who love C++
aren't able to keep up with all these changes because we aren't at the cutting
edge and don't need most of this esoteric functionality they are adding.

It feels like a runaway train and if there's a few more iterations I'm going
to have to give up trying to catch up because at that point it's easier to
just spend my time becoming an expert in another language like Java or Scala.
To mix another metaphor, it feels like the steering committee is outpacing
it's supply line of users and in 2-3 more iterations, there will be such a
wide swath of functionslity that it will be a complete mess because there will
be too much fragmentation of the language over a relatively short time period.

~~~
meetingcpp
2008? There never was a C++08...

Last Standard was 2003 before C++11.

~~~
steven2012
You're right, sorry I got mixed up between 2003 and Visual Studio 2008 which
is the IDE I used frequently back then.

~~~
ohyesyodo
I've been writing c++ on and off since Visual Studio 6. I would be glad to see
it move faster. I don't have to learn all esoteric things - I can pick and use
parts which I like, such as auto, for-each, smartptr, lambdas and so on. There
was a version 2003 and then C++11. Almost a decade later. How can that
possibly be too fast?

------
TillE
Named arguments would be lovely. It's quite exciting to C++ adopting all sorts
of modern conveniences relatively quickly, after a decade or more of
stagnation.

------
etimberg
I like the unified call syntax proposals. The one that has the potential to go
bad quickly is operator. which I forsee being used to create some painfully
obfuscated code.

------
amelius
Imho the problem with C++ is that it has gained too much weight over the
years. I think that other languages, for instance "Rust", will eventually fix
everything that C++ is forced to do wrong (due to its legacy), and these new
languages will become more and more attractive to use as a development
language.

Some things I personally hope will be added to C++ and/or Rust:

\- coroutines

\- lightweight threads

\- garbage collection (for high-level stuff)

\- a natural form of metaprogramming (not the convoluted approach taken by the
boost libraries), i.e., active libraries that generate code based on given
parameters

\- pure, lazy functional programming (language subset), e.g. for concurrent
stuff

\- pattern matching

~~~
nly
> the problem with C++ is that it has gained too much weight over the years.

> Some things I personally hope will be added to C++

... and therein lies the problem with language design ;)

------
Maken
_The basic suggestion is to define x.f(y) and f(x,y) to be equivalent_

Am I the only one who thinks this is terrible from a semantic point of view?

~~~
wyager
That does seem terrible. Right now those two things are, semantically,
completely different.

~~~
saurik
Except for operator overloading, where they are weirdly sometimes the same.
Also, the semantics of Koenig (aka, "argument dependent") lookup really play
into the matter, as they are effectively similar to member functions. As
someone who has been writing C++ now since 1996, I will say that this change
feels entirely natural and even "satisfying".

------
quotemstr
What I dislike about most of these proposals is that they make C++ even harder
to parse. It's important that tools other than full compilers be able to make
sense of program text.

~~~
nly
> It's important that tools other than full compilers be able to make sense of
> program text.

Depends. Qt Creator now embeds Clang itself to do just that. Visual Studio is
basically the same philosophically.

------
read
To the same place it will lead C++. A dead end.

------
Animats
Another round from the C++ committee. More features, not more safety. That
crowd just doesn't get it.

About a decade ago, I suggested to the C++ committee that their avoidance of
dealing with the memory safety issues in C++ constituted material support of
terrorism. They were sufficiently worried to delete that posting from their
USENET feed. So, a decade later, C++ has as many buffer overflows as ever.

