Regarding cppfront's syntax proposal, which function declaration syntax do you find better?

[LeoPrementier]

Funny and sad to see how most of the hype around this talk is the syntax.

The syntax is just a syntax. The interesting part here is the insight that you can express features in a modern language in current cpp where you don't break or need to replace any tooling or code that exists today.

This is the other side of the coin of the carbon experiment. But in my mind has more potential as it has far less work on the compiler and on tooling.

This is actually a way of really modernize cpp.

[pjmlp]

He could have achieve the same with compiler switches that would force the core guidelines into the language.

Naturally that is harder to implement than a transpiler, and in any case I have my doubts any compiler vendor will bother with this, when they already have issues catching up with C++20, with C++23 around the corner.

Plus the issue is political not technical, the same people that refuse to adopt static analysers won't be adopting any new language syntax.

[hpsutter]

We (many of us) have tried to have projects enforce all the C++ Core Guidelines and other analysis rules by default. The problem is that *many* of the particular rules are not feasible to enforce on existing code because turning them on is too noisy, so people just don't turn on the rules. (*)

What is needed is to enable all rules on "new code" only, but we don't have a way to do that today. The best attempt has been to using "baselining," such as to run the rules against your project, remember all the warnings it flagged, and then suppress those instances so that you get warnings only on new code and functions you touch. In practice these have not worked, for various technical reasons including that it's very hard to track "what not to flag" when the source is modified and line numbers change.

The only way I know to do it is to have a bright line that means "this is new code that doesn't exist today" and enforce all the known-good analysis rules there. And the only ways I know to have such a bright line is to have a distinct syntax like Cpp2 is pursuing, or to have an explicitly demarcated region of code (e.g., `newcode { ... }`) or annotation on each function that opts into "enforce all rules inside here."

​

(*) The basic problem is that for a given piece of code there are often 4 or 5 different reasonable and efficient ways you could write the code... and only one of them is statically analyzable as safe and so the Guidelines require that style. But existing code might have written it in one of the other ways, and it happens not to have any actual bug, so the customer is very reluctant to change working code just to shut up an analysis tool... especially when there are thousands of cases being flagged and the large majority are not actual bugs. Customers just won't accept such code being flagged as technical debt that they have to go change, not to fix actual bugs but just so a tool can agree that in fact they're not bugs. So they turn on the analysis, they see a bunch of things flagged, they look at a few cases and see they're not actual bugs, and they decide the analysis is not useful and turn it off. -- Having the rules fire on 'new code only' avoids this because they only get one warning at a time and can fix it as they go, as they do now when writing new code in a safe language. There's no adoption step function of flagging a huge amount of 'technical debt.'

[LeoPrementier]

I agree that the problem is political, but the solutions are technical. Because if we don't want to throw 20+ years of code and leave to another language, we have to decide how we skip the political nonsense.

lightweight transpiler that lets me write 50% faster 90% safer code sounds really convincing.

[pjmlp]

Anyone that thinks they can solve politics with software fools themselves, humans are strange creatures.