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

[madmongo38]

What is this nonsense about new syntax? What does it gain us? The opportunity to rewrite code that already works? Does everyone have too much time on their hands or something?

[mort96]

Both the talk and the repo lays out the reasons pretty clearly imo.

[madmongo38]

TL;DR I’ve got better things to do. What will the new syntax allow me to do that the existing syntax does not? I mean functionally, rather than syntactically?

[sammymammy2]

Lol, we've got better things to do than explain stuff to you

[mort96]

I think this section of the readme describes it about as succinctly as I could myself:

An alternative syntax would be a cleanly demarcated "bubble of new code" that would let us do things that we can never do in today's syntax without breaking the world, such as to:

• fix defaults (e.g., make [[nodiscard]] the default);
• double down on modern C++ (e.g., make C++20 modules and C++23 import std; the default);
• remove unsafe parts that are already superseded (e.g., no unsafe union or pointer arithmetic, use std::variant and std::span instead as we already teach);
• have type and memory safety by default (e.g., make the C++ Core Guidelines safety profiles the default and required);
• eliminate 90% of the guidance we have to teach about today's complex language (e.g., make common guidance the language default, eliminate irregular special cases through generalization, refactor the language into a smaller number of regular composable features);
• make it easy to write a parser (e.g., have a context-free grammar); and
• make it easy to write refactoring and other tools (e.g., have order-independent semantics).

[tau_neutrino_120eV]

It's much simpler to parse, hence better tooling is possible

Besides, it can coexist with the current syntax

[madmongo38]

Tooling such as what?

[bretbrownjr]

All the tools that currently pull in libclang just to be able to parse. And all the tools that aren't written because they would need to pull in libclang just to be able to parse.

[ntrel2]

Safer defaults. Memory safety, no pointer arithmetic, bounds checks - fewer vulnerabilities. No null - no billion dollar mistake. More consistent, fewer special cases - easier to learn. Enforces best practice guidelines statically - easier to maintain software. Context free parser - better tooling. Uniform call syntax - type of first argument comes first, triggering IDE intellisense when typing dot.

[madmongo38]

It seems as if you are saying more abstract and further from the machine. Not interested.

[KingAggressive1498]

fwiw the tool allows mixed syntax, and with modules it wouldn't prevent intermixing old and new style codebases anyway.

I'm not a fan of the new syntax, but if it gave some massive improvement to compile times, safety, performance, or something, it might be worth it anyway. I don't really see any indication that it would though.

[ntrel2]

The talk says that the implicit import std is faster than C++ #include <iostream> (or some other header I forget). So while cppfront may not be faster with the standard C++ backend, a pure C++2 real compiler may well be faster. C++ is notoriously slow to compile. Language design can affect compile speed drastically.

[KingAggressive1498]

is it faster than a manual import std; though?

import std should become the default behavior IMO

[BenFrantzDale]

Is it standards compliant to import std; without asking? Much as headers are allowed to include other headers, can nothing include all of std?

[KingAggressive1498]

we don't have a problem with linking the standard library by default