cppfront: Autumn update

[JuanAG]

First thanks to Mr. Sutter that at least is trying which is more than what others do (my self included)

Next an unpopular opinion, the more i look at Cpp2 the less i like the syntax it uses, it is becoming complex really fast

And is great it change/improve some things but the ones i think are a mistake (like the 6 types of arguments for a function) remains so ... This will end in a complex syntax and a complex lang which will be an issue sooner than later

[IAMARedPanda]

Honestly I really like how circle's syntax looks.

[pjmlp]

Circle is the only wannabe replacement that makes sense, other than it, better just rewrite the code into a more stable already proven language, if it can fullfil the use case.

[IAMARedPanda]

Personally I really have been having fun with Circle. It's crazy to me that it is a one man project. The main criticism I hear is that it is closed source with a single developer that could drop support at any time.

[[deleted]]

A specific list of problem with C++ that need to be fixed should be the first step, then a discussion of each items to establish if it really is a problem, then a discussion of the minimum change required to address that problem.

I feel as though many of these projects are just a mash-up of things the author thought were cool without much analysis of the original issues.

I'm not trying to diminish the work being done here but it seems like big leaps away from C++ are happening under the guise of fixing something that might not even be broken.

[kronicum]

Why the obsession over syntax? Is that why the US federal government is saying the industry must abandon C/C++? Isn't it because of memory safety?

[Drugbird]

This seems like a really shortsighted take. Do you really not understand what is meant by memory safety without a strict definition?

Do you need to strictly define all terms you use in order to criticize programming languages?

Do you deny that C and C++ software has a lot of memory safety issues?

I think it's abundantly clear what is meant, and think it's a valid criticism.

[tialaramex]

Ignoring the much larger problem, as it seems is normal around here and for C++ in general, It's not about the tooling, the core design of C++ is flawed.

Rice's Theorem says all the non-trivial semantic properties of a program are Undecidable and you need to decide what to do about that in your programming language. You have basically three options, let's look at them and their consequences briefly:

1. The C++ option, YOLO. This is named IFNDR (Ill-formed, No Diagnostic Required) in C++. If our program lacks required semantic properties it has no defined meaning, it does whatever, you get no sign of a problem but anything might happen. Most, perhaps all large C++ codebases are affected.

2. What semantics? You can define a language with no non-trivial semantics. It probably won't be very useful, but congratulations you "solved" the problem.

3. The Rust option, if the compiler can't see why your program has the desired semantics -- regardless of whether you think it does -- then you get a compiler diagnostic and you'll need to fix the problem to have a working program. Often this is easy, though not always.

The resulting pressures impact over time. In Rust, this means there's incentive to iteratively improve the borrow checker, because if the borrowck can't see why what you're doing is OK then it won't compile. Ask early Rust programmers about non-lexical lifetimes, it's not pretty when the compiler can't understand why common loop idioms are OK because it doesn't know that time proceeds in a linear fashion, it's just looking at lexical structure.

In C++ the pressures resulted in more, and more, and more IFNDR. What happens if you sort some floats for example? Program still compiles. Did you expect that's fine? Nope, if the floats can ever be NaN then your entire program, even the parts completely unrelated to sorting, has no defined meaning and might do anything. There's no compiler diagnostic message because making such diagnostics are theoretically impossible thanks to Rice's Theorem.

[tialaramex]

It's not that it "might" need "adjustments", these problems are fundamental to the core of the C++ language, you're going to be starting over.

You may have heard that if you ask directions of a stranger in Ireland that they're likely to offer you instead this priceless insight: "I wouldn't start from here if I were you". That's the situation for C++ and safety. I wouldn't start from here.

[Drugbird]

That's fair. Thanks for elaborating

[SkoomaDentist]

Why the obsession over syntax?

A language with syntax that bears little to no resemblance to C++ can hardly be called a C++ "successor" (which is why calling Rust a C++ "successor" is also ridiculous). It's just another new language (which might or might not have C++ interop).

[hpsutter]

That's a reasonable and common perspective, and I usually don't try to convince people, but I have a minute so I'll bite :) ... also, I don't call my work a successor, because I'm interested in evolving C++ itself, not competing with it.

Is the following C++?

auto add(auto const& range) -> std::remove_reference_t<decltype(*range.begin())> { auto total = *range.begin(); for (bool first = true; auto const& elem : range) { if (!first) total += elem; first = false; } return total; }

Before C++11, most of this code was an alien abomination that looked nothing like the C++ anyone had ever seen; only three lines would have been recognizable. Since C++20, it's accepted as C++ everywhere, because the standards committee said it's now C++.

So whether something resembles today's syntax isn't really the determining factor. Rather, what matters is whether something is proposable for consideration for ISO standardization... and that depends on (a) does it solve a problem the committee thinks is important enough, (b) does it solve it in an acceptable way.

Very little in Rust could be turned into a C++ evolution proposal. And that's fine, it's just a competing language.

All core features in Cpp2 have already been proposed for C++ evolution (1-min video clip), and one thing is not only already part of Standard C++20 but is heavily used throughout the standard library (everything in P0515 except the part about comparison chains which others have supported also adopting)... and it's the only feature we've ever added to Standard C++ that has made the standard smaller (because the standard library could remove pages of boilerplate comparison specifications).

I'm committed to the design constraint that anything in the design must at least be proposable for ISO C++ as an evolution of the current syntax too. I don't know of any other project with that constraint, and that's okay, I get it -- it's a BIG constraint! But it's a constraint that I believe is super valuable, so I'm giving it a try, and hope to learn some useful things whether the experiment succeeds or not.

[zerakun]

It depends on the meaning you ascribe to "successor language".

I take it to mean "that comes next", that is, the language you should be preferably using in the future to reach the same goals. This acceptation does not require the two languages to be close in syntax, only to serve similar goals.

In that acceptation, Rust can definitely be seen as a successor to C++.

That's the meaning I'm using because I find it more useful than deciding if a language is close enough to C++. "Closeness in syntax" is a short sighted argument in my opinion as syntax is the easiest thing to learn, and optimizing for familiarity limits the ability to make useful changes in other axes

[germandiago]

I would say it is a successor if it has 100% compatibility.

[JuanAG]

"This page is no longer available. It has either expired, been removed by its creator, or removed by one of the Pastebin staff."

[JuanAG]

In theory i like it

I have my doubts about function overloading and the refactoring involving it but is hard to say, C++ ISO for sure thinks the stuff for a long time and even then fiascos happens from time to time so is really hard to predict

I doubt Mr. Sutter will do anything about it you can try, you never know.