[koja86]

You might find this project kind of interesting:

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.

[Koshkin]

> 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

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.

[rl3]

>Sir, ...

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.

[echelon]

> it seems Rust has legacy baggage of its own already

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.

[rl3]

The notion extends to official libraries, not just the language itself. That said, I'm not the best person to ask, but cursory research turns up a few examples.[0][1][2][3]

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

[koja86]

Thank you in both cases sir/madam/whatever :-)

[adelarsq]

Some things still are on nightly builds, so will take some time to be perfect, at least for me. I have plans to use in production on next months =)

[SomeStupidPoint]

Just to point out: biological evolution uses changes in the base features utilized (epigenetics) to speed adaptability to changing environments (or new environments).

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.

[enqk]

> ...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.

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.

[akavel]

Is anybody aware of any compiler/tool which tries to enforce those rules? ideally, on code blocks enclosed in some special markers?

[RossBencina]

Clang-Tidy [0], in particular see the cppcoreguidelines.* checks [1]

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

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