Then you break backwards compatibility. What about static analysis to enforce a particular subset of features deemed idiomatic or otherwise best practice?

Granted, reducing complexity does make the job of future compiler authors far less miserable.

I like that idea.

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...

As a day-to-day C++ practitioner I like it.

...Yet I am not fully convinced that the general idea of language evolution implemented as ruleset outside of the language itself is the way to go. Seems more like band-aid to me and made me start to think about concept of programming language's life cycle in context of Darwinian evolution - once either legacy compatibility burden is too big or that particular biotope of specific problems the language solves better than others vanishes/changes the language dies out.

My particular issue with C++ is that it's complexity, longevity and evolution made possible for widespread bad-practices as not every C++ developer evolved as much as the language itself and it's general public understanding. (Some current best-practices were simply not always widely known or accepted.) I would even go as far to say that most of existing C++ code is crap (at least from standpoint of today "modern" C++).

And that's why I am both eagerly looking to "next generation" being shaped up by people who has (hopefully) learnt from past mistakes and used by people who care (itching to give Rust a ride once it stabilizes just a bit more) and also occasionally digging in the history for possible gems that I might not able to see without my current experience (platonic weekends-only relationship with Haskell, Lisp being right there at top of my TODO list).

EDIT: Removed the sir.

I think you are right - as far as 'the' language is concerned. The complexity (and the slowness) of a C++ compiler now is mostly due to the complexity - and the slowness - of the built-in interpreter of the template meta-language. There are other, saner languages, such as Common Lisp, where the meta-language is indistinguishable from the language itself, which, in addition to its greater simplicity, greatly contributes to the reasonable compile times. In the C/C++ land, it might have been possible to use a similar approach instead of introducing a separate macro/template syntax, a good example being the approach taken in the design of ASP (active server pages), PHP, and the like.

You may want to take a quick gander at the profile of whom you're replying to. :)

>... itching to give Rust a ride once it stabilizes just a bit more ...

Likewise, though from my limited research it seems Rust has legacy baggage of its own already, and there's difficulty in coming to a consensus on what qualifies as idiomatic Rust. It seems that the same principle of cherry-picking a subset of features would apply just the same to Rust as it does to C++. The latter being far messier, of course.

What is considered legacy cruft in Rust? The only change I'm aware of was the introduction of the `?` operator to replace the `try!` macro. That's easy to find/replace.

Some of these aren't examples of legacy cruft per se. However, as complexity is added to a language at a rapid rate, there becomes more confusion over what best practice actually is.

[0] https://www.reddit.com/r/rust/comments/2r7ttq/where_to_find_...

[1] https://users.rust-lang.org/t/rust-version-support-in-librar...

[2] https://gist.github.com/lifthrasiir/cedb5db8dbcd209c5957

[3] https://users.rust-lang.org/t/is-this-idiomatic-rust/2155

There's every reason to think that evolving human systems should use similar masks on features of a technology to make it more suitable for a particular domain and serve as a signal to drive the base evolution.

The restricted C subset used for safety critical systems I think is a good example of this -- the restriction allows for usage in a domain where the full set of features is a disadvantage.

What most people nowadays recommend programming in is actually not C++, and actually C++ + all compiler warnings, which is in itself an extension/evolution/restriction of the underlying language. So it's not so far out to go from there to externalizing more rules around valid programs.

[0] http://clang.llvm.org/extra/clang-tidy/

[1] http://clang.llvm.org/extra/clang-tidy/checks/list.html

I love the Objective-C convention of just using three-letter prefixes for everything. I'll miss its pragmatic approach.

Sadly these days, I'm not paid to "solve problems". I'm paid to solve them in C++ —sometimes for good reasons.

Google has a team and special toolset to do just that.

Also, how to use swap correctly? (Now, with std::move is less relevant though):

  template bla-bla {
     using std::swap;
     swap(result, computed);
  }

It's still ridiculous - calling a function should be easy :(

[1] http://en.cppreference.com/w/cpp/iterator/begin