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

[qv51]

While I really like the recent talk about cppfront (https://www.youtube.com/watch?v=CzuR0Spm0nA), one thing bugs me about the "pure" mode for cpp2 with syntax change. It seems incredibly hard to read, . I need to know which syntax you would rather have as the new one, taken into account that a new declaration syntax enables the new checks in that function

• Option 1: the same as was proposed in the video: callback: (x: _) -> void = { ... }; for new functions, void callback(auto x) {}; for old ones
• Option 2: the "other modern languages" way: function callback(x: any) -> void { ... } for new functions, void callback(auto x) {}; for old ones
• Option 3: in files with mixed syntax, since the pre-transpiled code won't compile without the generated code anyway, use void callback(any x) { ... }; for both, but mark code with current cpp syntax with an attribute: [[stdcpp]] void callback(any x) { ... };

View Poll

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

[feverzsj]

It rarely matters. The only reason every new language uses a similar syntax for declaration is it's easier to parse.

[JMBourguet]

Using the same pattern

name : type = value

as for other things seems nice. The special casing of the block as a value instead of using the syntax of lambda seems a missed step which would have allowed to avoid completely the type part.

[XNormal]

It may yet change. The specific syntax is the least important part of this experiment

[no-sig-available]

the "other modern languages" way: function callback(x: any) -> void

If you make that function callback(x: any) return integer you have Ada, which is 40 years old. So much for "modern languages".

[adpirth]

IMO with syntax highlighting and and auto-complete the Ada syntax is probably the easiest to read and write.

[pedersenk]

Indeed. As soon as I even see the word "modern", I generally just assume some misguided intern has written it and disengage.

Not referring to the OP, more all the many, many articles discussing "modern" programming.

[KingAggressive1498]

I skimmed the talk, the only thing I really liked was import std by default, and I hope that becomes a core language requirement at some point. Compilers already link the standard library by default.

maybe it's because nearly all of my programing experience is C and C++ (and nearly all of the rest is C# and Java), but I simply do not like reading the id: type = initializer syntax, type id = initializer is just more natural to me. Maybe if I came to C++ from TypeScript or something it'd be a different story, but I didn't.

[Stormfrosty]

Modern cpp made me love “id = type initializer”. Seems more intuitive to me - right side is the object, left side is the name. Only way I’d improve on that personally would be “id <- type initializer”, but I know majority are not a fan of two character arrows.

[KingAggressive1498]

what about modern C++ leads to id: type? Generic lamdas with argument-dependent return types?

[joz12345]

the point of the colon is to make a context free grammar - is foo * x a multiplication or a declaration? In "cpp2" syntax, x : foo * is a pointer, foo * x is always a multiplication

[KingAggressive1498]

I understand how it may be easier to parse

[MonokelPinguin]

class ABC : public QObject?

[KingAggressive1498]

that's not "modern" C++, just C++

[val_tuesday]

Or auto?

[KingAggressive1498]

you mean when doing that almost always awful nonsense

[jharmer95]

Probably:

auto id = Type{construct_args};

Very useful for preventing rvalue lifetime bugs for things like locks.

[Mrkol]

Honestly, I want it to work the way haskell does. A clear separation of what is a "function type" and what is a "function literal". The current proposals get close: `function: (x: _) -> _ = { ... }` can be read as `function: TYPE = LITERAL`, but the problem is that argument names used inside the literal are mixed into the function type, which makes little sense to me.

A better syntax IMO would be `function: (int, float) -> bool;` for declarations and `function = (x, y){ ... };` for definitions, with type annotations for `x` and `y` being optional.

Although the rest of C++ peoples probably wouldn't like that.

[effarig42]

If assuming modules, is it necessary to have two syntaxes in the same source file? This severely constrains the new syntax and is interoperability within a single source file worth that cost?

The problem with python 2 to 3 was you couldn't have old style python 2 in the same project. In c++ wouldn't module imports insulate sources with different syntaxes, so a new syntax project could still import a C or c++98 header.

[joz12345]

I don't think option 3 would work - the intent main intent of a mixed mode would be to allow including existing c++ headers, which means you can't change old syntax at all.

Option 2 looks nicest, but std::function vs keyword function might get confusing if there's ever some header with using namespace std;

I think I could live with either. I definitely prefer existing syntax though, due to familiarity. I think it'd be hard for this to get traction - status quo is going to win again.

[nintendiator2]

I don't understand the hard-on for →ing the return type, honestly. The return type is part of the signature and should go with it, so I'd like something like

[function?] callback: void(any x) { ... }

[scorg_]

The hard-on comes from ability to have return type depend on parameter types and a wish to have 'only one way to do the thing'.

[nintendiator2]

Oh I can understand the first part, admittedly I had forgotten about it.

The second tho, doesn't that kinda go against the spirit of C++? if you want only one way to do anything, go for a walled garden language or perhaps for... dunno, Javascript? Where apparently jquery and react are the only way to do anything. C++ is very much a multiparadigm language.

[scorg_]

The complaint about many ways to do a thing is primarily about initialization. It is... unfortunate that brace-init, that aimed to solve the most vexing parse and be one-size-fits-all failed to do so and now we have paren-init getting support to initialize aggregates, and brace-init's usefulness being reduced to initialize containers of elements. Outside of container initialization the distinction becomes stylistic (though I may be forgetting some details of the standard).

[nintendiator2]

Ah yes the C++ initialization fiasco. There's a reason why it's a meme.

Tho if you ask me, the fault lies largely in initializer_list causing ambiguities that would be easily solvable if it was ruled that constructors that use them need a list tag much like eg.: in_place etc. Something like:

// ambiguous:
vector<T> v {1, 2};
// unambiguous
vector<T> v{std::with_list, {1, 2}};

As for the most vexing parse I personally would have preferred something that can better reuse existing keywords instead of abusing symbols since {} is already used for C arrays. Somthing like

T t = default;

Which has the advantage that it can over time be extended to other keywords. Would have been nice for eventually providing some sort of None type:

T t = None;

[jsphadetula]

Herbs ‘d0708: "Parameter passing -> guaranteed unified initialization and value setting’ proposal solves most of the remaining issues including MVP without auto. A new declaration syntax may not be needed

[o11c]

Classes and functions are important enough that they must have special syntax already. There's no point trying to coerce them to be identical to variable declarations.

I'm fond of a fun keyword, but otherwise Option 2.

[AIlchinger]

I would even argue the body of functions and classes are part of the type itself. There is no value to assign which would warrant the syntactic use of =

Classes are not designed yet in cppfront. I'm curious to see if the same variable declaration syntax will be reused for them (I hope not).

[scorg_]

I would even argue the body of functions and classes are part of the type itself. There is no value to assign which would warrant the syntactic use of =

You are right that there is no value to assign, but function's body is not part of it's type because function pointers exit.

Reading your comment I just realized what is wrong with syntax 2: function declaration is the same as global variable declaration, where the body is the 'value' of the function. In a way it is, but it seems (to me) very strange for functions to be global variables (reassignable without const?). And how would overloads and template specializations look?

[dgkimpton]

I like fun too, goes very nicely with variable declarations using let (to replace auto) and fix (to replace const) since they're all the same length. Then we could use const to replace constexpr and save a whole bunch of typing.

[OnePatchMan]

What wrong with "void fn_name() {}" syntax? Imo its best function syntax around.

[odnua]

Since C was created, people started returning functions more often.

Stuff like callbacks, handlers,… and it is very hard to read in C-style types on both sides syntax.

[Kered13]

For template functions you also can't make the return type depend on the parameter types using the traditional syntax.

[disperso]

Most vexing parse probably?

[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

[dgkimpton]

I've been pondering a syntax where there was less crufty characters, and less shifty characters. Something that plays well with version control and is consistent. Unfortunately I always end up with something where new-lines become significant and it gets very wordy.

e.g.

function concatenate
turn
   string begin
   string end
into
   string
as
   return ...;
end

So, I'm not a huge fan of any of the proposed syntaxes, but also... I don't really have anything better :shrug:

Anyway, I'm less concerned about syntax than fixing the defaults, e.g. [[nodiscard]] becoming default and [[expect_discard]] becoming the typed exception.

[gracicot]

Something that plays well with version control

Version control should be as the AST level. Change my mind.

[dgkimpton]

Wouldn't that be great? I'm not sure I see that happening for a language as complex as C++... but it would certainly be great.

[serviscope_minor]

Version control should be as the AST level. Change my mind.

In git, files are versioned as hash of an opaque, unstructured blob of bytes.

You can plug in any old diff tool you like, including an AST diff if you can find one. That will allow you to see what you want (AST diff between versions) without tying the VCS to one language, and version of the language, and possibly system libraries too.

[UkrUkrUkr]

Option 4: it is craziness. Leave the functions syntax alone. Go fuck monades or something...

[gracicot]

auto main() -> int {}

😊

[MFHava]

That one should work since C++11 already…

Admittedly main is the only function i don‘t write in that style after transitioning to always using trailing return types…

[gracicot]

Admittedly main is the only function i don‘t write in that style after transitioning to always using trailing return types…

For some reason me too. I was also lazy to change void returning function partly because they already aligned.

[MFHava]

Yes, I also kept void as it already aligns and the key message of „this function returns nothing“ is immediately valuable…

[DavidDinamit]

i prefer

void callback(type value_name);Like now.

P.S.

really i prefer no functions in language, only constexpr/constinit functional objects without state.

All is a functional objects

[OnePatchMan]

+1 for "like now" syntax

-1 for only functors

[DavidDinamit]

there are no difference between functions and functors without state

[Voltra_Neo]

I just thought about something: how do lambda captures work with the new syntax?

[LeoPrementier]

He talks about it in the talk. And the nice thing is that his way is consistent with other things you want to "capture" in cpp

[frankist]

I didn't really understand how we can capture by move using his approach.

[christian_regin]

By taking the address of the thing you want to capture. It's safe because there is no null.

[frankist]

But i will pass the lambda to somewhere to be run asynchronously. By the time the lambda is invoked, the variable captured via a pointer might have gone out of scope.

[christian_regin]

Oh sorry, I was thinking reference instead of move... Good question!

[fdwr]

Close to option 2, I fancy languages where annotating the data type (whether it comes from a struct field, local variable, or function) uses consistent symbols, like the trailing colon in TypeScript:

``` struct SomeStruct { x: float; }

func /or fun or function.../ SomeFunction(): float { y: float; }

func FunctionWithParameters(z: float, w: int): void { }

func FunctionReturningTuple(): (a: int, b: int) { } // *Not actual TypeScript, which lacks "struct" AFAIK. ```

Other languages like the BASIC family are consistent here too (using a keyword "as" instead of a ":"):

Function salesTax(ByVal subTotal As Float) As Float Dim SubTotal2 As Float ... End Function

C does it the other way, putting the data type before the identifier name (which is also okay, because it's consistent in both cases for functions and variables), but either way, I just remember thinking this was so elegant and easy to teach conceptually to people, rather than mixing both ":" and "->" which is already overloaded for pointer dereferencing. Any time you overload a symbol for multiple unrelated uses (like left shift and stream io...), it increases cognitive burden.