[HN Gopher] Cppfront, Herb Sutter's proposal for a new C++ syntax
___________________________________________________________________
Cppfront, Herb Sutter's proposal for a new C++ syntax
Author : pjmlp
Score : 369 points
Date : 2022-09-17 14:31 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| IYasha wrote:
| >>
| https://github.com/hsutter/cppfront/blob/main/CODE_OF_CONDUC...
|
| That's why we can't have nice things. And also: no examples?
| bigbillheck wrote:
| It's Herb Sutter, you don't have to worry about it being
| enforced except on critics.
| (https://twitter.com/pati_gallardo/status/1561093468121956352)
| einpoklum wrote:
| Thanks for pointing out that terrible wart. Codes of Conduct
| are typically warning signs in themselves, but many of them -
| including this one - are markedly repressive and authoritarian:
| Criticism is forbidden except to the extent and in the forms
| which illustrious project leadership decrees (and is of course
| determined ex-post-facto), and it is the duty of leadership to
| excommunicate/cancel people who act in ways they don't like,
| for the greater good of the community. Naturally, I've phrased
| it in unforgiving terms, but it's all in the text.
| aappleby wrote:
| ... did you even read the code of conduct?
| einpoklum wrote:
| Oh, I did. And with a legal background including arguing
| multiple cases in different courts in my country. That's
| why it's scary.
| net_ wrote:
| Man, the negative sentiment on this site towards C++ is pretty
| alien to me.
|
| C++ is (I'm guessing) currently holding up an order of magnitude
| more applications than whatever you think is better than it.
| Clearly it has upsides, so it's baffling to me when people greet
| attempts to reduce the downsides with either "This doesn't make
| sense, just scrap it for something else" or endless nitpicks
| about the approach chosen.
|
| A smart guy has decided to put his time towards improving a
| hugely influential language. That seems like an uncontroversial
| positive to me, and I welcome any useful results.
| pjmlp wrote:
| C++ is a great language, the sub culture that keeps unsafe C
| patterns alive in the language, not so much.
|
| Example, back in the heyday of C++ frameworks bundled with
| compilers, bounds checking strings and collection arrays were
| the default.
|
| Nowadays you either call at(), have your own bounded checked
| types, or enable the debug library, but naturally without
| influence on 3rd party depedencies.
| 0x457 wrote:
| I think not many people ever got properly introduced to C++.
|
| Some probably only saw it during their format education, and
| it's most likely been taught like C with classes and/or they
| had to use for stupid things.
|
| There are also many forms of C++, there is your "old and
| regular" C++, game dev C++, there is modern C++, then there is
| "I only know C, but sure I can write C++" C++.
|
| Pulling dependencies is not as simple as `npm i boost`.
|
| Communities are small, segmented and not welcoming to newbies.
|
| Absolute madness with build tools. I've never worked with CMake
| myself until last year, and I haven't so frustrated.
|
| As for how many applications using C++ that's not really an
| argument -- C++ was literally the only choice for many of them
| at that time.
| mattgreenrocks wrote:
| My theory is that the Internet generally hates multi-paradigm
| languages (Scala!). Key phrase there is "the Internet," which
| is a euphemism for "people who write in the comment section."
| They aren't a representative sample, just a vocal one.
|
| There are plenty of good reasons to hate on C++, but that's
| conflated with a lot of "real hacker" signaling.
|
| Most takes on C++ lament that it isn't C, or is too complex.
| Rust is a quality replacement for C++, but it doesn't succeed
| on either of those counts either.
|
| All new code I write is in Rust or Haskell. If I need to do
| something weird, like with DynamoRIO, C++ it is.
| nine_k wrote:
| My problem with C++ is that, with all its complexity, it's
| still unsafe. Efforts to add safety to it as a,library
| (unique_ptr, etc) are commendable and useful, but they cannot
| be comprehensive, because the language's design, especially
| the early decisions, resists them.
|
| Lack of modularity and the fact that everything is treated
| like a single source file (via #include) adds interesting
| ways of unexpected interactions.
| riffraff wrote:
| Python and Ruby were considered multiparadigm languages once,
| and the internet didn't hate them at all.
|
| I think "the internet" tends to complain about languages
| which have accrued complexity over time, and contain parts
| that are now considered bad but still lurk in the shadows
| tripping you up.
|
| Scala, C++, perl and others seem to fall into this category.
| ryukoposting wrote:
| C++'s main upside is that it's the least common denominator.
| Also its runtime is friendly to embedded systems (kind of).
|
| I welcome good replacements for C++'s syntax, because it's
| genuinely terrible.
| zhxshen wrote:
| The text-include compilation model is broken, larger projects
| pay dearly for this, and thanks to C++'s very long history &
| very long feature list, there is a veritable Babel of feature
| subsets & compiler opts to choose from. Adding new dialects and
| features is not an improvement here.
| klodolph wrote:
| This is what the "modules" feature in C++20 addresses. People
| are complaining about modules a lot, I think because the spec
| is a little complicated... but the spec is a little
| complicated because the problem is a little complicated, and
| you can't pretend that complexity doesn't exist when you're
| writing the spec. (There are some other complaints about the
| modules system. It wasn't going to please everyone.)
|
| New dialects and features were getting added to JS all the
| time, but what happens is people writing JS libraries or
| tooling would watch how far these features spread in their
| users' browser compile base, and many of these various
| features would never even make it into popular JS runtimes,
| while others are everywhere now.
|
| I think it's a reasonable model for development--lots of
| people trying to improve things, the community slowly sifts
| it out, and the standards are the most conservative of all.
| bsder wrote:
| > This is what the "modules" feature in C++20 addresses.
|
| This is the perennial "If you only used _modern_ C++, you
| 'd be fine."
|
| Sorry. People have been repeating this for 15 years, and it
| hasn't gotten any more true.
|
| For example, C++ _still_ doesn 't have a useful string type
| --everybody rolls their own. How do you interoperate when 2
| different _C++_ libraries can 't even agree on something as
| basic as what a "string" is? The existence of "header-only"
| libraries and the contortions they go through is a tacit
| admission that compiling and linking C++ is _still_ a
| disaster. C++ _still_ doesn 't have a stable, documented
| ABI--so everybody defaults to C (thus throwing away any
| theoretical usefulness C++ might have). Embedded shuts down
| 90+% of C++ beyond "C with classes" because they can't use
| exceptions and can't allocate memory dynamically. The
| preprocessor is a brain parasite that has grown with C/C++
| and can't be removed anymore without killing the host. etc.
|
| In fact, I would argue the lack of stable ABI is the only
| thing propping C++ up. Because the C++ ABI is so shitty,
| you have to make the top-level code C++ which then calls
| into the other libraries and subsystems which actually have
| useful, stable and documented ABIs and interfaces.
|
| If C++ had an ABI that didn't suck, you could invert that,
| drive the C++ from the better language, and everybody would
| relegate C++ to increasingly tinier libraries until they
| could excise the remaining code and throw it into the
| trash.
|
| I feel for the people who put in their entire lifetime
| trying to "improve" C++. However, it's time to admit that
| C++ can't be fixed and move on.
|
| How amazing would it be to have people like Stroustrup and
| Sutter being paid to work on a language that doesn't start
| with unfixable suckage?
| forrestthewoods wrote:
| People complain about modules because they only exist on
| paper.
|
| Not a single compiler supports the standard library as a
| module. No compiler has full support for modules.
|
| Modules are a C++20 feature that isn't usable in real
| projects in 2022. And there's no signs that modules will be
| ready anytime soon.
| klodolph wrote:
| Is there something I'm missing? People are complaining
| because modules aren't supported yet? Isn't it reasonable
| to address this complaint by adding module support to
| compilers, and isn't this what's already happening?
| nine_k wrote:
| People are still feeling the pain, and are still
| complaining.
|
| I suppose when GCC and MSVC will both support modules in
| an interoperable way, these same people will enjoy and
| praise this development.
| throwaway-blue2 wrote:
| As I understand it modules support goes beyond just
| compilers - yes you need support there, but also in
| libraries (std library still is still not available as a
| module yet but apparently in progress) as well as build
| tools (CMake, Bazel, etc.).
|
| People are complaining because it's 2022 and support for
| modules is seemingly not there or incomplete in all these
| places, and modules are talked about in some C++
| communities as if they're a thing that is actually usable
| (for example Bjarne's talk at Cppcon a few days ago).
| humanrebar wrote:
| > People are complaining because it's 2022 and support
| for modules is seemingly not there or incomplete in all
| these places...
|
| So they're complaining on the internet about not getting
| free stuff fast enough.
|
| They could work with the maintainers of their toolchains
| instead. If everyone that used xcode complained to apple,
| C++ modules would be done there already. MS likewise
| would probably put more resources on it. Open source is a
| little more complicated, but Red Hat and Canonical do
| have paid products.
| zhxshen wrote:
| > because the spec is a little complicated
|
| Patching over the old work--hopefully without breaking
| anything--always is. I'm just stating that much of the
| hostility toward C++ comes from the fact that we have so
| many superior options to choose from now--options which
| profited from the lessons C++ learned the hard way, and
| incorporated them into v1 instead of patching them in as
| options at v23.
|
| And this is not to strikeforce anyone with a " _Rewrite it
| in Rust!_ ", but to suggest that C++ is maybe not the best
| choice for new work in 2022.
| otabdeveloper4 wrote:
| > programming is hard, let's go (language) shopping instead
| alar44 wrote:
| I will probably get some flack for this but it's an effect of
| the Python generation. When you can pull in some libraries and
| build some bloated slow as hell code in minutes, no one cares
| what's under the hood. The tradeoff from performance (easily
| 1000s of times, I've seen it swapping out simple python libs
| for c++, specifically changing dicts to linked lists) to ease
| of slapping things together makes me sad daily.
| lolinder wrote:
| Why would a trade-off make you sad? For most code that gets
| written, being able to quickly make something work is far
| more important than a 1000x increase in performance. Some
| projects do need performance, and for those no one should
| choose Python. For all the others, I'm glad Python exists.
| zozbot234 wrote:
| > C++ is (I'm guessing) currently holding up an order of
| magnitude more applications than whatever you think is better
| than it.
|
| So what. No one's going to rewrite all of those million lines
| of code in New C++, or whatever they call this incompatible
| syntax. It's just a distraction from more relevant efforts.
| pavlov wrote:
| New code can be written in the new syntax, with full access
| to existing libraries.
|
| I could easily see a company like Meta adopting this. They
| have both a huge amount of C++ code as well as actively
| developed guidelines and internal libraries that make use of
| cutting-edge features.
| the-smug-one wrote:
| If you've got 10^6 LoC of a product that will be developed
| and maintained for 10+ more years then you can slowly replace
| it with this.
| lallysingh wrote:
| This isn't a language declaration, it's a tool declaration. A
| tool useful for prototyping new language features and
| compiling them into large existing source bases.
| pelario wrote:
| From the link:
|
| "I'm sharing this work because I hope to start a conversation
| about what could be possible within C++'s own evolution to
| rejuvenate C++, now that we have C++20 and soon C++23 to
| build upon."
|
| Clearly this is relevant for c++ itself (coming from Sutter),
| so I'd say it's quite unfair/misguided to call it "just a
| distraction from more relevant efforts."
| zbird wrote:
| Of course they will. What they are less likely to do is to
| rewrite it in a completely different language (e.g. Rust.)
| C++ became popular in the first place because it could easily
| go along with C. No need to rewrite in bulk.
| Gibbon1 wrote:
| If you had a better syntax and modules that fix C++'s
| broken (as in slow) compilation model, why on earth would
| you write anything in Rust?
| stormbrew wrote:
| The thing is that C is _still_ the lingua franca abi, so
| there 's still no need to rewrite in bulk, you can still
| just use the same C libraries in another language, and rust
| is particularly well suited to doing that in roughly the
| same ways C++ is.
|
| What's getting harder and harder to see now is why, if you
| need to write new or rewrite now, you'd choose C++ over
| rust. In the long run that's a recipe for only the most
| gnarly old codebases being written in c++ and no one
| wanting to touch them.
| fortran77 wrote:
| We're starting new projects today, in 2022. (We do Signal
| Processing code for the Position, Navigation, and Time
| industry.)
|
| It's all C and C++, and Python if we need a scripting
| front-end. (Prototypes are done in matlab). "Rust"
| doesn't even exist in our universe. I don't think the
| people on HN are really in touch with how real people
| program in the real world.
|
| And on few the occasions when we have to do a complex
| desktop GUI app, we'll use C# or F#. We can get cross-
| platform Windows/Linux easily this way.
| jolux wrote:
| > I don't think the people on HN are really in touch with
| how real people program in the real world.
|
| I mean, I'm a real programmer in the real world. I think
| most people on here are. Rust is already in heavy use at
| Microsoft, Amazon, and Google, it's not some fringe thing
| anymore.
| lallysingh wrote:
| A lot of companies started with Java or Go, and will
| consider Rust without ever touching C++. The stigma alone
| is enough to turn people off.
|
| Hell it's going into the kernel in 6.1.
|
| C++ runs a real risk of surviving only in the
| embedded/realtime space in the next 10 years.
| bsder wrote:
| > C++ runs a real risk of surviving only in the
| embedded/realtime space in the next 10 years.
|
| Embedded/realtime? No way. The people I know in embedded
| won't touch C++ with _your_ 10 foot pole.
|
| Most of my embedded code is wrangling various "stacks"
| into cooperation with one another, and C++ helps me not
| one whit with that. At the other side, when I'm just
| poking sensors, C is more than enough.
|
| And, as much I would really like embedded communication
| stacks to be in Rust, all that would happen would be the
| vendors slapping "unsafe" on everything so they would
| basically be writing C anyway.
| sidlls wrote:
| More or less this. "Unsafe" as a value proposition loses
| its luster when it's ubiquitous in a code base.
| mrkeen wrote:
| 10 years? That feels too short.
|
| C++ is all the operating systems and the browsers and the
| games and the JVM.
| SubjectToChange wrote:
| > The stigma alone is enough to turn people off.
|
| C++ has been hated for decades now. The reason it's used
| is often because you _have to_.
|
| > C++ runs a real risk of surviving only in the
| embedded/realtime space in the next 10 years.
|
| Ten years from now C++ will still be the language
| underpinning LLVM, web browsers, geometric modeling,
| machine learning, etc
| sidlls wrote:
| Rust is still fringe even at FAANG level companies. I
| work at one such and we have a service or two written in
| Rust. I like Rust as a C++ replacement in the right
| context, but for 99.999% of applications it's not better
| in any qualitative or quantitative way than C++. Or Java.
| Or Go.
| fortran77 wrote:
| > Rust is still fringe even at FAANG level companies.
|
| Yes, everyone knows that, except for HN users! While I'm
| sure there are managers at large companies who let some
| employees play with Rust, it's not used.
| stormbrew wrote:
| I mean, I'm a HN user who just left one FAANG for another
| and I'm pretty confident this is changing a lot faster
| than you think.
|
| The thing that obscures this, I think, is that at most of
| them the surface area that the intersection of C, C++,
| and Rust that is high availability, security critical
| software, makes up a relatively small portion of what
| they do no matter what language it's in.
|
| So while there's a lot of C++ at say, Google and Facebook
| (but relatively little at Apple IME), very little of it
| needs to be in c++ let alone Rust.
|
| But where it matters? You better believe big companies
| are shifting towards "if you're starting new you should
| seriously consider Rust" (if not a mandate). And once you
| let one other language into your mix, the question
| becomes: why's all the high level stuff written in c++?
| May as well start new projects in Go.
|
| Some are farther along than others but it's a thing.
| sidlls wrote:
| The number of teams at these companies where "you should
| seriously consider Rust" is a thing is _approximately_
| (not exactly) zero. Its adoption is still a novelty, and
| most of the impetus behind it is engineers looking to
| scratch an itch without any legitimate analysis of the
| benefits or trade-offs involved.
|
| It may be changing, but certainly not faster than I've
| observed (it's not a matter of speculation, for me).
| fortran77 wrote:
| But the world isn't FAANG. There are thouasands of other
| companies doing interesting things.
| stormbrew wrote:
| I didn't say it was? We're talking about faang in this
| sub thread.
| [deleted]
| carlhjerpe wrote:
| How do you write GUI apps in C# with Win/Linux support?
| Usually people don't go C# if they're doing GUI on other
| things than Windows. CLI/Server software is a first class
| citizen on Linux these days though.
| fortran77 wrote:
| There are many ways!
|
| https://halfblood.pro/the-story-about-net-cross-platform-
| ui-...
|
| I like to use Xaml. For iOS/Android there are solutions,
| too.
| kllrnohj wrote:
| > The thing is that C is still the lingua franca abi, so
| there's still no need to rewrite in bulk, you can still
| just use the same C libraries in another language
|
| No. C is the lingua franca for _exported public stable
| ABIs_ , which is an _extremely_ small subset of any given
| program 's ABI usages.
|
| C++ ABI is just as widely used as C's, just for internal
| unstable linkage instead of stable exported linkage. So
| yes you still need to rewrite in bulk to move off of C++,
| unless your code happened to be tiny & only used C API
| libraries.
| CamperBob2 wrote:
| That's true, but at the same time, modern C++ bears about the
| same resemblance to the C++ that many (if not most) of us
| learned years ago, as modern English bears to Middle English.
|
| People have been trying to make the language safer and more
| palatable for multiple decades now, so it seems reasonable to
| allow Sutter to have a go at it.
| guitarbill wrote:
| It doesn't feel much different to any other language that
| people have been burned by (e.g. Javascript). I have some bad
| C++ experienced, and I know enough programmers I respect who
| stick to C over C++.
|
| Of course it's difficult to equate that kind of advice/feedback
| to negative comments on HN. But often, there's some kernel of
| truth there. So while there's some merit to C++, the criticism
| can equally be valid. And keeping the underlying complexity of
| C++ (similar to how Carbon will) might not meaningfully
| simplify development).
| einpoklum wrote:
| > I have some bad C++ experienced, and I know enough
| programmers I respect who stick to C over C++.
|
| Do you know such people who work on large software systems,
| as opposed to, say, micro-controller firmware, or kernel
| drivers and such?
|
| (Asking as a person who maintains an important(ish) C library
| for embedded coders: https://github.com/eyalroz/printf)
| Galanwe wrote:
| On the top of my head, for large open source C codebases
| that are not system/kernel/controller I guess Python, Ruby
| and Redis would be good examples.
|
| I do myself fall in the category of people sticking to C
| over C++. I used to love C++ back until c++03, then
| completely hated the whole "new generation c++" orientation
| that started with c++11 and pretty much decided to not
| touch c++ anymore.
| jcelerier wrote:
| I think that "large" really needs to be defined here.
| CPython is 350kloc of C. I have seen C++ codebases with
| more source files than there are lines of code in that.
| Just the "base" module of Qt is ~4million loc
| 1024core wrote:
| > Do you know such people who work on large software
| systems, as opposed to, say, micro-controller firmware, or
| kernel drivers and such?
|
| Redis is written entirely in C.
| summerlight wrote:
| I don't think that Redis qualifies as a large software
| system in the modern standard. In fact, it's popular
| because it's simple, small and understandable compared to
| its competitors which comprises of many millions of lines
| of code.
| einpoklum wrote:
| Redis is ~200K lines of C code, so it's relevant project-
| size-wise, but - redis was started in C, right? It's not
| like developers now have the option to "go C++" without a
| company-wide decision.
|
| Still, if could quote Redis developers making the GP's
| claim, that would count.
| jrockway wrote:
| I really don't think Redis is a large software system.
| Things like Firefox, Chrome, AAA games, etc. are what I'd
| call large C++ systems.
| mek6800d2 wrote:
| I used to work for a company whose product was a fairly
| large satellite control center software system (and we
| could supply hardware if needed), written in C++. It's used
| for a lot of commercial fleets. For example, back in the
| 2000s, when I worked on it, it was used for
| CDRADIO/Sirius's fleet. (I don't know if it's still used
| for SiriusXM's Sirius satellites, if any.)
|
| I liked C++ in some ways, but as a whole, I think, C++
| didn't reduce -- and may have increased -- the complexity
| of our software compared to the complexity of an equivalent
| C implementation. (I'm talking about the complexity of the
| software itself, not the complexities of the tasks it was
| doing.) The distribution of the complexity in the code
| would just have been different between the two
| implementations. IMHO.
|
| So I mostly stick with C or other non-C++ languages now. Of
| course, C++ has expanded and changed greatly since then.
| ncmncm wrote:
| You would be very pleasantly surprised at how programming
| in C+ is, today, vs. pre-C++11. With C++20, the language
| has got even nicer to use.
| benj111 wrote:
| Familiarity breeds contempt?
|
| I'm sure many would dislike rust if they were forced to use it.
| Same with python, etc, etc, etc.
|
| I'm not saying the criticisms are wrong per se, but the reason
| we have so many languages is probably because there's no
| 'right' language.
| cplusplusfellow wrote:
| I'm truly thankful in my life for Sutter doing the work he does
| to make this language better. He is a giant.
| asveikau wrote:
| I came up with the following guess many years ago:
|
| There are people who are totally unproductive at C++ and find
| it scary, mainly because they are not very exposed to it. They
| assume everybody is as uncomfortable and unproductive with it
| as they are. Nay, it is _impossible_ for _anyone_ to be
| productive with it, simply because they aren 't. They will
| attack evidence that somebody has done well with it, because it
| is some defense of ego for them.
|
| There are other complaints about C++ beyond this of course,
| with validity, and many of them from old timers and people who
| bitterly complained about it for decades from a place of
| knowledge and experience. People have been complaining about
| ugliness of C++ for longer than my own career. However, as more
| and more people come up in the post-C++-as-fashionable era, I
| think this above theory is more and more the bulk of the
| complaints.
| bowsamic wrote:
| I agree, and I don't think it's as hard or complex as people
| make it out to be
| staticassertion wrote:
| > Clearly it has upsides,
|
| All that you've indicated is that it's used a lot, which is
| obviously because it has decades on every other option.
|
| Anyway, I love Herb Sutter and I love this work he's doing.
| Awesome stuff.
| throwaway894345 wrote:
| "Holding up an order of magnitude more applications ... clearly
| it has upsides".
|
| It's holding up lots of applications because better languages
| didn't exist at the time those projects were started, and it's
| rarely feasible to switch languages. Specifically, a lot of
| people look to Rust to unseat C++ for new applications, but it
| will take a while for Rust to mature with respect to libraries
| (e.g., game engines) and mindshare in those industries. But
| even then, old languages have tons of staying power by virtue
| of age.
| YZF wrote:
| I'm not super familiar with Rust, do you have SSE/AVX
| intrinsics (others?)? Can you write assembly embedded in Rust
| code? How does rust stack in terms of performance?
|
| https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
|
| looks quite decent, but overall Rust is still behind? So if I
| am in an area where performance (or cost/energy) is king then
| I'd still pick C++.
| tialaramex wrote:
| Rust's std::simd is the portable abstraction but it is so
| far only available in nightly Rust, in principle you would
| be able to write code that does SIMD on whatever hardware
| (ARM, x86-64, whatever) is targeted including AVX.
|
| Yes, Rust has inline assembly in roughly the same way you'd
| be used to with C or C++
|
| https://doc.rust-lang.org/reference/inline-assembly.html
|
| The Benchmarks Game has a bunch of benchmarks, and while
| it's probably significant that the Python programs are
| routinely orders of magnitude slower than say C, we likely
| shouldn't read too much into whether somebody scraped a few
| more milliseconds off the best time for one of the
| benchmarks listed.
| the_jesus_villa wrote:
| I don't know the answers to all of your questions, but
|
| >Can you write assembly embedded in Rust code?
|
| Yes, I've done this several times. It looks like this:
| https://doc.rust-lang.org/rust-by-example/unsafe/asm.html
| agersant wrote:
| > do you have SSE/AVX intrinsics (others?)?
|
| Yes. https://docs.rs/simd/latest/simd/
|
| > Can you write assembly embedded in Rust code?
|
| Also yes. https://doc.rust-lang.org/reference/inline-
| assembly.html
| dento wrote:
| SIMD intrinsics exist, although currently require nightly
| compiler on non-x86 targets: https://doc.rust-
| lang.org/1.29.0/core/arch/x86/index.html
|
| Inline assembly: https://rust-
| lang.github.io/rfcs/2873-inline-asm.html
|
| Performance is almost identical, even the linked benchmark
| is quite even.
| uoaei wrote:
| I think your argument is analogous to saying "Why do so many
| people hate Facebook? Clearly it has upsides, it connects so
| many people together and promotes a lot of economic activity."
|
| If "network effect" is the sole reason you like a thing, and
| there are many valid criticisms of how that thing goes about
| its business, maybe there's a reason people criticize it so
| openly?
| Volker_W wrote:
| > C++ is (I'm guessing) currently holding up an order of
| magnitude more applications than whatever you think is better
| than it.
|
| You could say the same thing about COBOL.
|
| (Not that I think that C++ is as bad as COBOL.)
| hvs wrote:
| C++ is like the English language. Extraordinarily popular, hard
| to learn, and full of weird cruft. You can write amazing things
| in it as well as terribly unsafe garbage.
| stefanos82 wrote:
| I feel so sad for hours now...well, from the time I saw the
| original post on reddit and then here.
|
| For the past few days all I can see in HN is the announcement of
| new languages and research projects that relate to C++:
| * Carbon (https://github.com/carbon-language/carbon-lang) *
| Val (https://www.val-lang.dev/) * Jakt
| (https://github.com/serenityos/jakt) * now Cppfront...
|
| Is everything alright within ANSI / ISO committee?
| ncmncm wrote:
| There is no voice of the committee.
|
| A breakaway group, including Google and Microsoft, has sought
| to break backward link-compatibilty, and has failed. So they
| are pursuing other avenues.
|
| Probably the single most valuable improvement possible while
| retaining C++'s strengths would be to fix initialization syntax
| and semantics. Second would be to simplify and limit implicit
| conversion and promotion for base types.
| protomyth wrote:
| In The Design and Evolution of C++ by Bjarne Stroustrup there is
| some interesting discussion on alternate declaration syntax that
| was rejected because it wasn't compatible with C. The book also
| explains a lot of design decisions that would be interesting to
| revisit in light of what has gone on.
| astrostl wrote:
| Is that tiny, illegible-in-dark-mode hello world the only example
| or am I missing something? For as much content as there is in the
| README I would hope that a syntax change would, well, show some
| more syntax comparisons.
| alcover wrote:
| Same with me.. are we both tired or is this whole thread about
| just the idea of a new syntax ?
|
| I scrolled the whole Readme. Are we supposed to parse the
| parser in /source ?
| mcluck wrote:
| The readme points to regression tests as the best example of
| the different syntax
| onedognight wrote:
| The README points here for a bunch of examples.
| https://github.com/hsutter/cppfront/tree/main/regression-
| tests/test-results
| bumblebritches5 wrote:
| Night_Thastus wrote:
| EDIT: I am dumb, my brain automatically thought import std was
| "using namespace std" for some reason.
| Jtsummers wrote:
| That default import doesn't pollute the namespace like you seem
| to think it will, look at the hello world example in the
| readme, note that the `std::` prefix is still present.
| spayce wrote:
| "main: () -> int = { hello("world\n"); }"
|
| Kill it with fire.
| Koshkin wrote:
| The semicolon cancer is still there. Good.
| tricky777 wrote:
| semicolons help the parser. easier to point where erroneous
| statement began.
| neutrono wrote:
| how is auto main() -> int { hello ("world\n"); } any better?
| stjohnswarts wrote:
| looks like they crossed rust and javascript and came up with
| something worse lol
| sorenjan wrote:
| > import std; as default
|
| Personally I think he should switch to _using namespace std;_ as
| default as well. The compiler can warn if you alias the names,
| and all the std:: in C++ code is just noise and annoying to read
| and write.
| Koshkin wrote:
| But for backward compatibility you should be able to undo it,
| then. (Problem is, I don't think you can.)
| klyrs wrote:
| I think you're in a minority here. Off the top of my head,
| std::get should never be simply `get`. Here's a complete list
| of symbols that may or may not be defined depending on what
| you've included.
|
| https://en.cppreference.com/w/cpp/symbol_index
| sorenjan wrote:
| Ok, maybe bringing everything into the global namespace is a
| bit of a stretch, but you could at least do the most common
| ones. Who's going to alias cout or string?
|
| As for std::get, while it's a separate issue I think the
| problem that solves should be solved in a more elegant way if
| you're trying to reform the language anyway. This is not
| elegant: std::get<0>(arr) = 1;
| uwagar wrote:
| teachers, leave our c++ alone!
| gigel82 wrote:
| I don't get it. The code sample is way uglier and more difficult
| to read than modern C++. Just move your code base to modern C++,
| it's a pleasure to work in (not joking, I'm loving it).
| pjmlp wrote:
| The point is that you also get the right defaults and the C++
| Core Guidelines semantics without any additional tooling, which
| even with static analysis in C++20 isn't 100% there.
| 01100011 wrote:
| Drive-by, low-quality comment:
|
| Herb is great. Glad he's thinking about this. C++ syntax is
| garbage and needs help, but why deviate so much from existing
| syntax? Why drop curly braces? The decision to allow mixing
| new/old C++ syntax in the same file seems like a gross mistake
| that prevents a more incremental fix of the language. Why the
| heck doesn't it support defining classes yet? Is it because of
| the aforementioned requirement to intermix new/old syntax?
|
| I hope efforts like this continue, as we all know something is
| broken in C++ syntax. I think it can be fixed with tweaks and
| some breaking of backwards compatibility in the same source
| module.
| tricky777 wrote:
| why no classes? I assume that it's meant just as an initial
| sketch/demo. Doing 100% is at least twice as hard as doing 80%.
| [deleted]
| marsven_422 wrote:
| aappleby wrote:
| Programming languages are serialization formats for source code.
| cies wrote:
| I found this language recently that also compiles to CPPv1:
|
| https://github.com/SerenityOS/jakt
|
| Really nice feature set.
| stabbles wrote:
| Seems like C++ is having an identity crisis lately
| echelon wrote:
| C++ is getting the Perl treatment.
|
| Perl had Ruby, Python, and PHP attacking it. C++ has Rust, Go,
| Nim, and Swift (albeit that only Rust is a direct challenge,
| the others are taking market share for things that used to be
| C++). I've even seen people using Vala in new places.
|
| Perl was hard to use. The new languages addressed many of the
| ergonomics, semantics, and design concerns. Rust addresses a
| lot of C++'s dangerous baggage.
|
| Perl had novel tooling at the time, but eventually wound up
| behind. Newer languages brought more to the table. Rust has
| Cargo.
|
| Perl tried evolving for a long time. Eventually birthed a new
| language altogether (Raku), albeit that the old language still
| receives updates. (Python also saw this.) Google recently
| unveiled Carbon. Now there's Cppfront. The C++ language
| committee is doing different things...
|
| It's a question of which ecosystem evolves faster and
| ultimately which ecosystem attracts more fresh blood as old
| timers age out. AFAICT, younger developers are flocking to Rust
| instead of C++. There are a bunch of Rustlang streams on
| Twitch.
| mlinksva wrote:
| That's an interesting analogy that I hadn't seen before,
| simplified as Perl : Python :: C++ : Rust in terms of
| conjectural market adoption.
|
| As someone who did a lot of Perl in web 1.0 times, and
| haven't really been a full time programmer in a long time but
| occasionally have since written Ruby, Python, and PHP, but
| never really felt those languages were that huge of
| improvements over Perl (certainly now their ecosystems are,
| but I'd love a much better entrant to successfully "attack"
| Python), and would sometimes wonder what if Perl had just
| managed to evolve significantly instead...makes me appreciate
| and even root for efforts to "make C++ 10x simpler, safer,
| and more toolable" like this one or perhaps Carbon, even
| though Rust does seem like a huge improvement.
| cageface wrote:
| I wrote a lot of Perl in the first dotcom era and was very
| happy to switch to Python and Ruby as soon as I had a
| chance. There were some nice things about Perl but it was
| just too hard to maintain a large, active perl codebase
| with multiple engineers making commits. Perl coasted along
| for a long time on the momentum of CPAN but it wasn't
| enough.
|
| I think the C++ analogy makes sense. How many programmers
| entering the field today are choosing to learn C++ when
| they have so many other choices without all of C++'s
| baroque complexity and footguns?
| pjmlp wrote:
| Actually I think the PL/I treatment is closer as example.
|
| The language complexity was famous and eventually grew into
| several subsets before UNIX adoption wiping out most systems
| languages that sprung as PL/I alternatives.
| api wrote:
| Rust is eating it in systems and Go for applications.
|
| IMHO nothing but Rust or Go has any merit as a replacement
| unless it also bring the same safety. A fully unsafe language
| in 2022 is dumb. (Fully unsafe, not optional unsafety which may
| be needed in a systems language.)
| 3a2d29 wrote:
| "A fully unsafe language in 2022 is dumb."
|
| I think this is a subtweet at Zig, and while I am not a zig
| developer, I will point something out that everyone forgets
| (to defend C++ and Zig and the like): Some apps don't need
| memory safety.
|
| For example a single player game or application that runs
| just on your own machine, memory safety would just be another
| type of bug.
|
| If dealing with Rust's ownership rules is annoying and you
| don't want a GC, then you can certainly use an unsafe
| language. Not all apps are websites and browsers.
|
| I would also add (I could be wrong here) but I think things
| written in web assembly can also be unsafe, as the memory is
| in a sandbox. I think I heard this once, but I could be
| wrong.
| charcircuit wrote:
| >memory safety would just be another type of bug
|
| A bug that can be costly to reproduce and fix and has the
| affect of terrible UX and losing unsaved progress. If I had
| to choose a category of bugs to tolerate memory safety bugs
| would be near the bottom of the list.
| jstimpfle wrote:
| It seems like in terms of subjective productivity,
| memory-unsafe languages have going for them a lot.
| Otherwise how do you explain so many programmers still
| willingly choosing them?
|
| I know that in the domains that I'm interested in, I
| would be way miserable programming in something like e.g.
| Java, because I've figured out certain patterns that I
| know will work in a memory-unsafe language with very
| little friction, but that cannot be simply be translated
| to Java because of e.g. reference semantics.
|
| The same probably holds for other approaches to safety,
| like Rust. I'm not interested anymore in tight
| opinionated approaches to problem solving. I _love_ void-
| pointers and memcpy'ing stuff because these let me do
| abstraction with very low friction. Getting the job done
| very quickly, with very very low rate of bugs, and those
| get quickly fixed. (I'm not making a statement about
| multi-million line projects in corporate environments.
| This is about the situations that I run into,
| personally).
| charcircuit wrote:
| >how do you explain so many programmers still willingly
| choosing them?
|
| Lack of education + Legacy software / programmers /
| education material.
| kouteiheika wrote:
| > It seems like in terms of subjective productivity,
| memory-unsafe languages have going for them a lot.
| Otherwise how do you explain so many programmers still
| willingly choosing them?
|
| Honestly? And this might be a hot take - exactly the same
| way as I'd explain people rejecting structured
| programming way back in the day. It was the new thing on
| the block and people were not used to it, and preferred
| to just sprinkle GOTOs in their program just like they
| always used to do rather than learning a new paradigm.
|
| As someone who used to professionally program in C++ on
| an expert level in the past and now has completely
| switched to Rust I can tell you that (at least
| subjectively for me) Rust is way more productive than C++
| ever was. Once you internalize how the language works the
| limitations of Rust just disappear. You learn how to
| instinctively write code that's idiomatic, and it just
| stops slowing you down. But it also gives you _a ton_ of
| new features that end up speeding you up compared to C++,
| e.g. sum types, pattern matching, cargo, great standard
| library, destructive moves, proper modules, #[derive],
| good error messages, etc. Memory safety can also be
| significant productivity boost because you can (or at
| least I do) just churn out code without thinking about it
| too much and just rely on the compiler to make sure that
| it 's memory safe. Can this code trigger use-after-free?
| Is this iterator valid? What's the lifetime of this
| pointer? Instead of thinking about all of these you can
| use those brain cells for something else.
| api wrote:
| > Some apps don't need memory safety.
|
| Even apps that run locally and don't talk to the net can be
| vulnerable. How many break ins happen via bugs in PDF
| viewers, office packages, and media players? Look it up.
| PDF and spreadsheet vulnerabilities are very common.
|
| Then there's the productivity gain you get by not having to
| spend hours debugging obscure memory and threading bugs.
| The latter are not ruled out in Go or Rust but they are
| profoundly less likely to occur, making code that actually
| takes advantage of modern hardware much easier to write.
|
| After learning Rust and after having used C++ very heavily
| for years I can say that Rust is far more productive.
| azakai wrote:
| > PDF and spreadsheet vulnerabilities are very common.
|
| True. The issue is that they operate on complex input
| that can arrive from anywhere. So if you download a
| malicious PDF file it can exploit you.
|
| But GP's other example is valid: A singleplayer game
| running locally will only run the game assets from the
| developer. The user input (in almost all games) is very
| limited. Exploits are not a major issue in such a
| program.
|
| There is room for languages like Zig. There is also the
| potential for it to be used in improper places, but so
| far the majority of applications I've heard of seem
| reasonable to me.
|
| > Then there's the productivity gain you get by not
| having to spend hours debugging obscure memory and
| threading bugs.
|
| Also true. But there are the other usual tradeoffs, such
| as that a language focused on simplicity and correctness,
| like Zig, might reduce other sources of bugs.
|
| Some developers might be more productive with Rust,
| others with Go, others with Zig. I don't think there's a
| single answer here. As an example of another related
| tradeoff, fast compile times often help debugging, which
| is an advantage of Go and Zig.
| KerrAvon wrote:
| > A singleplayer game running locally will only run the
| game assets from the developer. The user input (in almost
| all games) is very limited. Exploits are not a major
| issue in such a program.
|
| Nothing is that isolated anymore. Can you find a modern
| single-player game on Steam that doesn't talk to the
| network for analytics or DLC or sending crash reports to
| the developer? I'm sure they exist, but they're likely
| exceptionally rare.
|
| For Zig to be helpful in the modern world, it will need
| memory safety guarantees and it will need them on by
| default. It's totally OK if those are easier to switch
| off than in Rust so that you can do the low-level things
| performantly and easily. But you have to start from a
| default position of safety.
| azakai wrote:
| Even if a game sends crash reports etc., it could be safe
| enough. Making a secure connection to a known remote
| server isn't a major source of exploits. (Look for
| example at the list of exploits against Firefox and
| Chrome - stuff like that isn't even noticeable.)
|
| I disagree every language needs to start with the same
| defaults as Rust. Rust proved its approach is a useful
| one, and Rust is a huge asset to our industry, but we
| also benefit from exploring other approaches.
| littlestymaar wrote:
| > Some apps don't need memory safety.
|
| Even setting security considerations aside, as soon as you
| have users, using a non-memory-safe language means having
| users reporting very unhelpful "bun crashes at startup with
| "segmentation fault""and good luck to figure out what's
| going on.
|
| > I think this is a subtweet at Zig
|
| Why do you think it's especially aimed at Zig? Zig is only
| one among others, like Carbon, or Cppfront discussed here.
| 3a2d29 wrote:
| I would agree that seg faults are not fun to debug, but
| if you think you can be speed up production and get the
| product done several orders of magnitude faster without
| ownership rules AND you can't use a GC, I do think it
| could be worth the trade-off.
|
| > Why do you think it's especially aimed at Zig?
|
| I honestly don't use zig so I really don't have a horse
| in the race, but when I read: "nothing but Rust or Go has
| any merit as a replacement unless it also bring the same
| safety. A fully unsafe language in 2022 is dumb"
|
| That seems to be targeted at replacing C++, which both
| Carbon and CppFront are not doing per se. Zig is the next
| big "low level replacement language" (that isn't Rust or
| Go) that HN seems to chat about so I took a guess.
|
| Again, I don't think that's too relevant to my point
| (although I am curious if OP wants to weigh in on what
| they meant).
| littlestymaar wrote:
| > but if you think you can be speed up production and get
| the product done several orders of magnitude faster
| without ownership rules
|
| If you genuinely believe that Rusts rules slow developers
| down by "several ordrers of magnitude" (which litterally
| means: "makes you 100 times slower or more") then you've
| probably listened/read way to much anti-rust discourse
| for your own good...
|
| Rust has a learning curve and in the beginning you're
| obviously going to be slowed down by the learning
| process, but for 99% of the tasks[1] once you've gone
| past the initial learning period, the rules aren't
| slowing you down since you've internalized them, and
| compiler errors end up being mostly about things that
| would have caused a memory bug in other low-level
| languages.
|
| [1]: that is, everything but custom graph data
| structures, which are really hard to get right without a
| GC anyway.
| 3a2d29 wrote:
| I actually have started learning rust and I do like it. I
| am hoping to get to a point where the ownership structure
| becomes obvious in my mind.
|
| If I had to make a game right now though, I would be way
| faster in C++.
|
| That said though, I do hope as I learn rust everything
| becomes obvious. I would be very happy if I get equally
| as productive (since that means I can use rust for
| everything).
|
| I guess I just worry that certain things are like custom
| graph data structures, where suddenly ownership is a huge
| issue.
| littlestymaar wrote:
| > If I had to make a game right now though, I would be
| way faster in C++.
|
| I've no doubt about that, _learning_ Rust sometimes feels
| like having to swim with your hands tied in the back.
|
| > That said though, I do hope as I learn rust everything
| becomes obvious. I would be very happy if I get equally
| as productive (since that means I can use rust for
| everything).
|
| Good luck:), don't be afraid to stop and try again a few
| weeks later if you get too frustrated: I struggled a bit
| to learn rust early 2016 and after a few weeks of night
| hacking, I had no more free time to carry on and I was
| still very confused about all of that. Then, I stopped
| for almost 6 months, having read of few blog posts in
| Reddit in the meantime but nothing especially eye opening
| or anything, and when I got back to Rust for some reason
| everything sounded clear and I completed my first project
| in Rust very smoothly, as if my brain had been slowly
| digesting the concepts in a background thread during that
| time.
|
| > I guess I just worry that certain things are like
| custom graph data structures, where suddenly ownership is
| a huge issue.
|
| Advice: avoid them as much as possible (most of my former
| use of graph-like structures where in fact related to
| programming patterns and not strictly necessary for what
| I wanted to do) and if you're really manipulating graphs,
| you should probably use a dedicated library (I think
| petgraph is the most popular but these kind of things can
| be workload dependent so you might need to go for another
| one).
| pjmlp wrote:
| Only because liability is still not a thing in software as
| in other regulated domains.
|
| > Many years later we asked our customers whether they
| wished us to provide an option to switch off these checks
| in the interests of efficiency on production runs.
| Unanimously, they urged us not to--they already knew how
| frequently subscript errors occur on production runs where
| failure to detect them could be disastrous. I note with
| fear and horror that even in 1980, language designers and
| users have not learned this lesson. In any respectable
| branch of engineering, failure to observe such elementary
| precautions would have long been against the law.
|
| -- C.A.R Hoare on his Turing award speech in 1981.
| 3a2d29 wrote:
| Against the law cause if you do this on a bridge, people
| die.
|
| If a play Civ V and it crashes, I just a bit mad.
|
| I will acknowledge though good engineering practices are
| important, maybe my perspective of "tolerance" of these
| bugs when they are isolated is missing the point.
| pjmlp wrote:
| If I play Civ V and it crashes, I want my money back,
| just like I won't stand a broken appliance.
|
| Thankfully App stores are already making this point clear
| to the industry.
| 3a2d29 wrote:
| Doesn't this counter your first point? A broken appliance
| isn't against the law.
|
| Second, I think data shows most people don't return games
| after 1 crash. In fact, I think getting to market fast is
| a bigger factor for profit.
| mrkeen wrote:
| Similar quote in a more recent video:
| Removing type checking from your running programs is like
| wearing a life jacket for your practice emergency drills
| and then taking it off as soon as your ship was really
| sinking
| https://www.youtube.com/watch?v=YYkOWzrO3xg
|
| Maybe that was right in the 70-80s, but I feel like he's
| not giving enough credit to modern static verification /
| type-checking.
| strictfp wrote:
| > Some apps don't need memory safety.
|
| Maybe not, but it's still a big pain in the butt to avoid
| bugs in that area. I imagine that static analysis for
| memory safety would be something that most developers would
| use in existing unsafe languages if they could.
| pjmlp wrote:
| Lint was created for C in 1979... to this day most devs
| ignore static analysis tooling for C and C++.
| KerrAvon wrote:
| Static analysis can be excellent, but it doesn't solve
| the whole problem.
| patrick451 wrote:
| For a lot of applications, that doesn't matter. It solves
| enough of the problem.
| pjmlp wrote:
| Indeed, still using it is better than nothing.
| rramadass wrote:
| Nah... It is just the ISO committee and its members mucking
| about.
|
| Many of us don't agree with the way the committee has been
| "evolving" the language and then mandating "the one true way to
| do _Modern C++_ ". At least with this "syntax 2" thing they
| will leave the language alone.
| dilawar wrote:
| Why can't they just improve tooling and dependency management
| first? After using Cargo, I now find Python's tooling unbearable.
| Once you have seen the other side, there no coming back.
| teo_zero wrote:
| I find it disappointing that the enhancements aren't explained
| one by one, or even listed. How am I supposed to decide if it's
| worth a deep dive?
| drummer wrote:
| [deleted]
| timsneath wrote:
| This is work that is 5+ years old. Before casually dismissing
| work that is long in the making, it's worth taking a moment to
| evaluate it. There are some amazing talks in the README that
| Herb has given. I particularly enjoyed his "Thoughts on
| Metaclasses" talk (https://www.youtube.com/watch?v=6nsyX37nsRs)
| which starts with a live on-stage user study.
|
| Herb's thoughtfulness and care for tasteful evolution is
| manifest in the way he describes his work, and it's a shame to
| see it disparaged so easily.
| zozbot234 wrote:
| > ... This is work that is 5+ years old.
|
| And yet it was released today, in a way that clearly a
| reaction to Carbon (which is, itself, a reaction to Rust and
| perhaps Swift to a lesser extent). The comparison is highly
| relevant.
| Jtsummers wrote:
| I don't know when he made the repo public, but the first
| commit was 2021. If this were published, say, the week or
| so _after_ Carbon were announced, maybe you could argue it
| was a reaction to it (though still, it started _before_
| Carbon was announced, in what direction does time flow
| again?). But a more likely reason for it coming out now is
| that Sutter gave a talk at CppCon last week on this
| material.
| WCSTombs wrote:
| It appears that the CppFront work has been in progress since
| 2015-2016, which would make it predate Carbon by a few years.
| michaelwww wrote:
| I've written C++ and understand it's appeal: high level
| abstractions with very little runtime penalty, but I also
| understand it's legacy issues that make it complicated. Instead
| of adding to C++ maybe we should subtracting from it like perhaps
| C-- : The good parts of C++
| blinkingled wrote:
| > Can we make C++ 10x safer, simpler, and more toolable if C++
| had an alternative "syntax #2," within which we could be
| completely free to improve semantics by applying 30 years' worth
| of C++ language experience without any backward source
| compatibility constraints?
|
| Yes please - I really like this approach. C++ as a bare bones on-
| its-own language is not going to find adoption in the new world -
| it is way too much baggage & legacy, syntax and functional
| complications and adding more complexity every 3 years is just
| counter productive. If this can become something like what Scala
| or Kotlin are to Java it would be good for C++.
| simias wrote:
| As someone who dropped C++ almost entirely a decade ago because I
| couldn't deal with both the immense complexity and the legacy
| baggage of C++, this is pretty exciting honestly.
|
| What I find a bit strange is that he explains that he's been
| working on this since 2015 (with "most of the 'syntax 2' design
| work in 2015-16") and he doesn't want to give documentation
| because "that would imply this project is intended for others to
| use -- if it someday becomes ready for that, I'll post more
| docs."
|
| Why this reticence to opening the project and have others play
| with it and, potentially, contribute to it? I can't imagine a new
| language becoming successful with this mindset.
| ablob wrote:
| I think it's more about losing control. As soon as the
| documentation is open, there is a lot more pressure to explain
| the decisions made in an accurate or accepted fashion. Add some
| good old bike-shedding or contributions that miss the point and
| a project that was once fun becomes tedious to work for.
| samatman wrote:
| It also adds a lot of drag to iteration to have to go back
| and rework documentation.
|
| On this kind of project, it's more than syntax-deep.
| Documentation would have a lot of reasoning and justification
| in it, which can take deep work to keep up to date.
| gumby wrote:
| A lot of decisions made, BTW, have been explained in
| proposals for the C++ committee that came out of this work.
| summerlight wrote:
| Yeah, I couldn't agree more. this is exactly what's happening
| in ISO C++ and Herb should be well aware of its problems
| since lots of his good proposals failed to proceed many times
| thanks to WG21 rife with all the bureaucracies and
| nitpicking. This kind of skunk works needs to be fully driven
| by a competent individual or small group until it's finally
| able to demonstrate a good value proposition and build trusts
| by the project itself.
| zulban wrote:
| > Why this reticence to opening the project and have others
| play with it
|
| I heard this recently: open projects are like Good Will Hunting
| but in reverse. You start as a respected genius, and end up as
| a janitor getting into fights.
| nsajko wrote:
| > As someone who dropped C++ almost entirely a decade ago
| because I couldn't deal with both the immense complexity and
| the legacy baggage of C++, this is pretty exciting honestly.
|
| This seems to be just a syntax frontend for C++. The underlying
| semantics stay the same.
|
| BTW, if you dropped C++ a decade ago, you should now look into
| the modern improvements (C++20).
| badtension wrote:
| What does the C++20 change in a day-to-day work? I know they
| added "stuff" (as always) but is there anything that really
| benefits >80% of all cpp programmers?
| jcelerier wrote:
| to me concepts and coroutines really reduce the amount of
| boilerplate needed.
|
| - just the ability of doing if
| constexpr(requires { T::some_member; }) { ... }
|
| to check if a type has a member variable / function /
| whatever makes code infinitely clearer than the previous
| mess requiring overloads.
|
| - coroutines finally enable to properly abstract the data
| structures used by a type's implementation, e.g. you don't
| need to spill out anymore that your type stores stuff in
| std::vector or std::array or boost::small_vector or
| std::list etc etc to client code, and they simplify async
| code very well. for instance with Qt:
| https://qcoro.dvratil.cz/reference/core/qprocess/#examples
|
| - three-way comparison and automtic generation of
| comparison / equality function is really great for removing
| needless boilerplate
|
| - void f(auto arg) { ... } instead of template<typename T>
| void f(T arg) { ... }
|
| - foo{.designated = 123, .init = "456" }; (although it was
| already more or less supported on every relevant compiler
| for years
| 8n4vidtmkvmk wrote:
| designated initializers are a trap. you can't require
| certain fields are set... this has been a big pain point
| for my team. guess we should have used builder pattern or
| something
| leni536 wrote:
| > you can't require certain fields are set
|
| There is a way, but it's cursed:
|
| https://godbolt.org/z/fzc6WEz5e
| ncmncm wrote:
| Clever. Wrap it in a concept, and it might have legs.
| tialaramex wrote:
| In principle Modules would be huge, but in practice you
| can't use them as the compiler you have doesn't implement
| them yet.
|
| C++ 20 gets a format feature that's basically a weaker
| {fmt} library but as part of the standard library. A string
| formatting feature with reasonable performance and safety
| as you might be used to from other modern languages.
|
| Concepts is nice, that's basically way to express duck
| typing, it is often described like you're getting more than
| duck typing but that's all you actually get - but hey, duck
| typing is useful, and Concepts should have decent error
| messages whereas doing the equivalent with SFINAE is a
| recipe for awful diagnostic output.
| ncmncm wrote:
| _Please do not post falsehoods seeking to mislead
| readers._ You have been corrected on this point several
| times before.
|
| In fact, C++ Concepts _can be_ used for early enforcement
| of compile-time duck typing, just for better error
| messages. In the Standard library they are commonly used
| that way, for backward compatibility.
|
| But Concepts can also implement named-property matching.
| It is entirely up to the designer of a library how much
| of each to present.
| tialaramex wrote:
| > You have been corrected on this point several times
| before.
|
| You have repeatedly (across numerous HN threads) insisted
| that Concepts aren't just duck typing but that doesn't
| make it so.
|
| > But Concepts can also implement named-property
| matching.
|
| That's still just duck typing (and it's awkward to do
| properly). Contrast with the (eventually abandoned) C++
| 0x Concepts, which actually has semantic weight to it.
| Concept Maps allow C++ 0x Concepts to have some sort of
| chance in a language that's already in widespread use,
| because you can adapt an existing type to the Concept
| using a Map.
|
| But C++ 20 Concepts doesn't offer any of that, after
| about a decade it's just duck typing.
| ascar wrote:
| Not really a C++ expert, but two things I saw in the
| documentation and that came in useful were the "contains"
| method of maps and the std::span class for passing around
| contiguous sequences of objects without worrying about
| creating copies of vectors.
| kllrnohj wrote:
| Compared to a decade ago a bunch of stuff in no particular
| order:
|
| 1) malloc/new & free/delete are now solidly legacy
| territory of the "unless it's a placement `new`, you're
| likely doing it wrong". make_unique && make_shared all day
| long.
|
| 2) templates that are understandable by mortals thanks to
| `if constexpr` instead of SFINAE nightmares.
|
| 3) static_asserts
|
| 4) lambdas (which is going to get way more useful with http
| s://en.cppreference.com/w/cpp/utility/functional/move_on...
| )
|
| 5) std::format
|
| 6) attributes like [[nodiscard]] being standard
|
| 7) std::move making passing std:vector & similar containers
| around not being terrifying (this is what also really helps
| #1 be possible)
|
| I'm sure I missed some stuff, but I reach for all of those
| regularly.
| rrss wrote:
| > Important disclaimer: This isn't about 'just a pretty
| syntax,' it's about fixing semantics
| gumby wrote:
| > This seems to be just a syntax frontend for C++. The
| underlying semantics stay the same.
|
| That is very much _not_ true. In fact the syntax
| simplification is of less interest to me than the
| clarification /simplification of semantics. Most of the
| dangerous / confusing parts of c++ come from the necessary c
| compatibility.
|
| So for example, you don't have to worry about the bug-
| inducing C integer promotion rules.
| xpe wrote:
| > if you dropped C++ a decade ago ...
|
| Fair. Still, the more recent C++ improvements tend to roll
| out slowly across the ecosystem and work environments.
| nicky0 wrote:
| Becoming a successful lamnguage does not seem to be a goal of
| the project:
|
| "Cppfront is a personal experimental compiler from an
| experimental C++ 'syntax 2' to today's 'syntax 1,' to learn
| some things, prove out some concepts, and share some ideas."
| gumby wrote:
| And this work has resulted in things that were discussed or
| even got into subsequent C++ standards.
| mort96 wrote:
| Because this isn't a new language which is attempting to become
| successful. This is a playground to experiment with ways to
| evolve C++ into a better language.
| simias wrote:
| All the more reason to have people play with it, no?
| bangonkeyboard wrote:
| Other people playing with and using it decrease his ability
| to make breaking changes freely.
| jlarocco wrote:
| It seems like other people should come up with their own
| "playground" for experimenting?
| wheelerof4te wrote:
| Looks like an unholy love child of Python, Javascript and Hare.
| OliverM wrote:
| C++ was one of the first languages I learnt as an undergrad,
| maybe 20 years ago. I used it for a few hobby projects but not
| much else (professionally these days I mainly use Typescript &
| Go). I'd love to pick up C++ again but I've found it really
| challenging to discover what I should read up on to know what
| modern C++ should look like. What's a great resource for someone
| who's been out of C++ for a couple of decades to pick up and
| learn today's idiomatic C++? I don't want Rust btw - it's a great
| language but I want to revitalise my C++ knowledge, not jump ship
| entirely.
| raegis wrote:
| I think Jonathan Boccara's talk, "105 STL Algorithms in Less
| Than an Hour" ( https://www.youtube.com/watch?v=2olsGf6JIkU ),
| gives a nice overview of the <algorithm> library. Also, the
| examples on the reference pages (usually near the bottom) at
| cppreference.com are usually pretty good. For example: Here's
| how to create a pseudo random number generator using the
| Mersenne Twister engine. std::mt19937 e; //
| Mersenne Twister engine
| std::uniform_int_distribution<int> u(0,99999); // uniform ints
| 0 to 99999, inclusive auto rng = std::bind(u,e); // so
| rng() retuns the next random number
|
| And filling a vector with random numbers could look like this:
| std::vector<int> nums(1000); std::generate(nums.begin(),
| nums.end(), rng);
|
| This last line can be written in C++20 more simply like this:
| std::ranges::generate(nums,rng);
| ncmncm wrote:
| Generally Cppreference.com has the most authoritative
| information on what C++ is now. It is _somewhat_ opinionated
| about modernity, but not enough so to be intrusive.
|
| Usage examples have often been updated to current best
| practice.
| detaro wrote:
| The standard recommendations to come to up speed up to ~C++14
| are Scott Meyers books, _Effective C++_ and _Effective Modern
| C++_ , but I'm not sure if they work well alone when you've not
| used C++ in a long time. And don't have a good recommendation
| for something covering the stuff newer than that.
| jpeter wrote:
| What is this obesession with the funcname() -> type syntax? I
| just hate it
| malkia wrote:
| Carbonfront....
| wrd83 wrote:
| Yeah. I think this is a response to carbon. See what google did
| with golang. It affects python and Java heavily. If carbon gets
| successful, this means less influence for cpp
| djur wrote:
| The project dates back to 2015, and the compiler work started
| in 2021, well before Carbon was announced.
| 3a2d29 wrote:
| While I would like to see C++ improve, I would argue that this
| really is reinventing the wheel when Carbon is being worked on.
|
| I guess the only thing cppfront would offer is mixed syntax
| within one file, but I could even see Carbon implementing
| something like that.
| lbhdc wrote:
| Compiler explorer supports cppfront
| https://godbolt.org/z/shYes883a
| mbotner wrote:
| I remain convinced that Herb is an amazing force of nature!
|
| Simply incredible from my mortal programer point of view.
|
| Wow!
|
| Mark
| zozbot234 wrote:
| "Fixing semantics" while keeping 100% ABI compatibility with old
| C++ seems really hard. It looks like this will have to allow for
| some kind of opt-in ABI breakage, at which point you're not far
| away from what you could achieve more easily by using e.g.
| Carbon, or just better Rust/C++ interop (see autocxx, crubit,
| creusot).
| [deleted]
| nsajko wrote:
| > far away from what you could achieve more easily by using
| e.g. Carbon, or just better Rust/C++ interop (see creusot).
|
| At that point, why not just upgrade to C++20? Carbon, in
| particular, is left behind in the C++17 world, so it's outdated
| by C++20 (not to mention future developments).
| TillE wrote:
| No one has ever said that Carbon will forever be frozen at
| C++17 compatibility. That's just the initial goal.
| mgraczyk wrote:
| Google is basically stuck in the C++17 world, so I wouldn't
| expect Carbon to move forward if they end up investing
| heavily in it.
|
| In particular Google hasn't even started to adopt C++
| coroutines, threading, ranges, or modules (they have their
| own module implementation which is actually better in most
| ways, but different)
| humanrebar wrote:
| Pros:
|
| - Transpiling to C++ means it will work wherever C++ works. On
| any toolchain. With relatively little effort. It shouldn't be
| hard to add CMake and bazel support, for instance. Even mostly
| dumb makefiles should be workable.
|
| - Approaching the community this way could avoid fracturing the
| community more than it already is.
|
| - Targeting specific success metrics (like CVE causes) could
| provide focus around design and requirements
|
| - Seems simpler and easier to learn and teach.
|
| Cons:
|
| - The pitch assumes C++ modules are implemented, ready to use,
| and reasonable accessible.
|
| - There will be a _lot_ of tooling to reinvent: static analyzers,
| syntax highlighters, etc.
|
| - At least for a while, debugging cpp2 problems will involve
| juggling multiple parallel realities: cpp2 code, C++ code, and
| actual program behavior (i.e. compiled binaries).
|
| - Doesn't address other major C++ ecosystem problems like build
| times, packaging, build systems, etc. cpp2 _could_ make them
| slightly worse.
| zozbot234 wrote:
| > Transpiling to C++ means it will work wherever C++ works.
|
| It also means you don't really benefit from any of the new
| semantics. Why do all of that static analysis work to establish
| safety, and then throw the results away by writing out clunky
| old C++? It all makes very little sense.
| zdragnar wrote:
| Transpiling and compiling are turtles all the way down.
|
| It's a bit more complicated than, say, typescript to
| JavaScript, but in spirit is not so very different, right?
| wasyl wrote:
| Because you don't actually work with the C++ output I guess?
| Same with Kotlin/Java -- there's no difference in nullable vs
| non-nullable types for example. But as long as your codebase
| is 100% Kotlin, you get proper null safety, and there's no
| need to fall back to what Java has
| ablob wrote:
| How are any of the guarantees lost as long as the resulting
| C++ code isn't touched?
| jcelerier wrote:
| .. this doesn't make sense at all. If you prove that a
| program is safe in language A, it doesn't magically become
| unsafe when transpiled to language B. Every language works by
| clunking out instruction sets mostly devised in the 1970/80s,
| this doesn't remove the safety properties of the higher level
| language.
| zozbot234 wrote:
| A whole program, yes. A library that's written for language
| A may well rely on arbitrarily complex preconditions for
| safety that you may have no hope of establishing within
| language B. Rust devs get bitten by this all the time when
| trying to reuse "safe" library code within an unsafe
| context. (That's one key reason for wanting e.g. Carbon as
| something that isn't just plain Rust.)
| neongreen wrote:
| Off the top of your head, do you have simple examples of
| this? I know a bit of Rust but I assumed (apparently
| wrongly!) that safe-within-unsafe should just work.
| zozbot234 wrote:
| It will work if your unsafe code does not actually opt-in
| to any unsafe features-- in which case you would not
| actually need an unsafe block. If it does use any of
| those however, it's very easy to break the expected
| preconditions of safe code and create unsoundness, e.g.
| around references (since code written in safe Rust has
| little use for raw pointers) or properly initialized data
| (Rust expects you to use MaybeUninit<> whenever data may
| not be properly initialized but that's a mere wrapper,
| which can only be removed by unsafe code).
| littlestymaar wrote:
| So if your unsafe code hits an UB then your safe code can
| be broken...
| kibwen wrote:
| Of course, undefined behavior anywhere in the program
| automatically makes the entire program invalid (this is
| how undefined behavior works in C and C++ compilers as
| well). But that's not what the parent commenters are
| talking about. An `unsafe` block in Rust represents a
| place where the ordinary invariants of the language may
| be violated. This is immensely useful for auditing,
| documentation, and manually verifying that the program
| acts as you expect. But it's a common mistake to assume
| that this also means that _future_ changes to non-unsafe-
| blocks cannot invalidate existing unsafe blocks. While it
| is always _necessary_ for an unsafe block to exist as a
| sort of "root cause" of unsafety, safety invariants can
| rely on things that are merely _reachable_ from unsafe
| blocks. In practice, this means that the boundary for
| safety in Rust is not the unsafe block itself, but rather
| the boundary of the module that contains the unsafe
| block. This also means that, if you 're writing unsafe
| blocks in Rust, it behooves you to make their containing
| modules as small as possible in order to reduce the
| amount of things the unsafe block can reach, and
| therefore reduce the number of changes that might
| accidentally change an assumption that an unsafe block is
| relying upon.
| littlestymaar wrote:
| I know about that (even though it's a worthwhile addition
| to this thread for other readers), but I don't think it's
| what they had in mind, since they were talking about
| "Rust devs get bitten by this all the time when trying to
| reuse "safe" library code within an unsafe context" in
| their original comment[1], and I really can't see what
| they are talking about except some variation around "from
| C++ I passed some uninitialized memory to a Rust library
| and Rust went boom" but maybe I'm just misunderstanding.
|
| [1]: https://news.ycombinator.com/item?id=32878775
| ekidd wrote:
| I'm not sure what the grandparent post if referring to,
| but:
|
| - In general, "unsafe" code inside a module may depend on
| invariants maintained by "safe" code in the same module.
| For example, the "length" field in a Vec can be changed
| by the safe internals of Vec. But if the safe code in Vec
| sets an invalid "length" value, then unsafe code relying
| on "length" might fail. So once you find an unsafe block,
| you may need to audit some of the surrounding safe code
| in the same module.
|
| - Unsafe Rust is actually slightly _less_ forgiving than
| C or C++, partly because Rust is allowed to set
| "noalias" on lots of immutable references, IIRC. The
| Rustonomicon talks a lot about issues like this.
| wizofaus wrote:
| That's exactly how Typescript works. The point is that the
| type-safety checks are done at transpilation time, and that
| step fails if you've violated them. So I'm assuming something
| similar for cppfront - it will fail to transpile if your code
| doesn't pass the additional safety checks.
| einpoklum wrote:
| > Transpiling to C++ means it will work wherever C++ works.
|
| Only if you only use this Cpp2 thing. Because the C++ you write
| may not play nice with the C++ this transpiles into.
| gumby wrote:
| It support the big 3 (gcc, clang, ms)
| projektfu wrote:
| The static analysis should be able to remain because a lot of
| the concepts he has implemented here are proposed/implemented
| for "syntax 1" as well, but they require attributes or specific
| styles. Therefore, the static analyzer should be written for
| regular C++23 and will support the defaults of "syntax 2".
|
| As far as support in compiled libraries is concerned, that
| would depend on how those features are implemented in C++23
| anyway.
| humanrebar wrote:
| Well, existing static analysis would break or need to add
| support for cpp2. In the case of pure cpp2, simpler tools
| could be written, but they would be new code.
| nikki93 wrote:
| I've been using my own little Go (subset / my own extensions)
| -> C++ compiler -- https://github.com/nikki93/gx -- and found
| it to be a fun way to add some guardrails and nicer syntax over
| C++ usage. You get Go's package system and the syntax analyzers
| / syntax highlighters etc. just work.
| lostdog wrote:
| > Doesn't address other major C++ ecosystem problems like build
| times, packaging, build systems, etc. cpp2 could make them
| slightly worse.
|
| I assume that as long as the cpp2 syntax is clean, you could
| improve on compile times. In theory, cpp2 files could compile
| much more quickly that C++, so as you migrate code to cpp2 your
| builds speed up?
|
| It all depends on how well Sutter has thought through the cpp2
| language design I suppose.
| humanrebar wrote:
| I said that because the user surveys conducted by ISO clearly
| identify dependency management and build times as the biggest
| pain points for C++ engineers. Every proposal doesn't have to
| work on those problems, but other than parsing (i.e.,
| language designer tech) tooling seems like an afterthought in
| this case. Just like all of the big ideas coming from ISO
| leadership.
|
| Big reasons people look for non-C++ solutions include better
| build times, dependency management, etc.
| wizofaus wrote:
| But it's adding an extra compilation step. The only way to
| will improve compile times is if it avoids the need to
| recompile all source files referring to header that's only
| been modified to add/remove/modify private methods/data in a
| class (even data is an issue if objects of that class are
| instantiated on the stack). In principle it might be possible
| for an extra transpilation step to help there if you also
| take over the "make"-style dependency management. I'm
| guessing c++ modules is supposed to help address this too?
| 3836293648 wrote:
| The idea is not adding a compilation step. This is a proof
| of concept and playground. If it works out it's not going
| to stay as a transpiler to Cpp1 forever
| lbhdc wrote:
| In his talk he demos mixing syntax 1 and 2 (his terms) in the
| same file. Preprocessor macros work fine unless you enable
| "pure" mode.
|
| He also demos error messages, and was able to get errors from a
| cpp compiler (msvc) that point to his cpp2 file with a line
| number and readable error.
| mort96 wrote:
| This is all true, but I feel it sort of misses the point a bit.
| The goal seems to be mainly to use cppfront as a test bed for
| new language syntax and semantics, where most of the ideas will
| eventually make its way into the C++ standard or into existing
| compilers.
|
| The main reason to use it in production is that it's not meant
| to be used in production and makes no attempt to be suitable
| for production use or avoid breaking changes, so the stuff in
| your cons list doesn't really apply. It's kind of like looking
| at someone's scale model of a proposed city layout and say that
| a pro is that tiny plastic houses are cheap to manufacture at
| scale but a con is that the houses may be too small to live in.
|
| But all of your points will become relevant if cppfront
| eventually gets to a state where it's a serious transpiler
| meant to be used in production.
| kvathupo wrote:
| I agree, and would like to note that there isn't a need to
| simplify C++ imo. It's folly from a business and productivity
| standpoint to use one language, especially C++, to do
| everything from writing web apps to doing exploratory data
| analysis.
|
| Besides, the C++ community seems to overlap with academia by
| way of its feature updates, reveling in complexity (e.g.
| "C++20 ranges are totally awesome: memory-safe and performant
| iterators!").
| cpeterso wrote:
| > Transpiling to C++ means it will work wherever C++ works.
|
| This approach is similar to Rust's editions. IIUC, nearly all
| of the differences been editions are compartmentalized in the
| frontend, deprecating syntax and rewriting old edition code to
| rustc's current IR.
| tialaramex wrote:
| Rust's Editions specifically only change the concrete syntax,
| although there have been hacks to make some stuff that would
| otherwise be impossible become possible by retrospectively
| making how things used to work a special case, and of course
| if some feature _needs_ syntax then you can 't use it from an
| Edition which doesn't have that syntax (e.g. async doesn't
| exist in Rust 2015 edition)
|
| Here's the guide explaining the most significant hack:
|
| https://doc.rust-lang.org/edition-
| guide/rust-2021/IntoIterat...
|
| There was a proposal to do Editions for C++, Epochs,
| https://www.open-
| std.org/jtc1/sc22/wg21/docs/papers/2019/p18... but it was not
| accepted.
| kibwen wrote:
| Rust editions can technically change some aspects of the
| language semantics, but this ability is used sparingly. An
| example is how the `iter` method on fixed-size arrays
| changed in the most recent edition. As long as code from
| all editions can still be used together, a semantic change
| is possible.
| tialaramex wrote:
| > An example is how the `iter` method on fixed-size
| arrays changed in the most recent edition.
|
| Can you explain?
|
| The array type doesn't have an iter() method. It will
| coerce into a slice, which does have an iter() method,
| but doesn't care whether it's an array we're slicing.
| kibwen wrote:
| I was misremembering, it was `into_iter` rather than
| `iter` that was changed. The documentation for the change
| can be found here: https://doc.rust-lang.org/edition-
| guide/rust-2021/IntoIterat...
| [deleted]
| ehzy wrote:
| That's not what they're talking about here. They're saying
| that any system with a C++ compiler is a target for this new
| language, as opposed to Rust, which only runs on systems with
| a LLVM backend.
| humanrebar wrote:
| Yes. This. Assuming some niche embedded cross compilation
| toolchain uses C++23, it would support cpp2.
| googlryas wrote:
| I'm sorry, but Herb Sutter is too smart for his own good. He
| should not be involved in language design meant for mortals. I
| mean, who can honestly say both "For me, ISO C++ is the best tool
| in the world today to write the programs I want and need", but
| then also "I want to make C++ 10x simpler/safer/more toolable"?
| kubb wrote:
| My impression is that many people use C++ because they need to,
| but not because they want to.
| ReptileMan wrote:
| Java and C# fucked up in that they thought that people really
| loved the objects, but missed that actually people really
| hated the pointers and the oo part was mostly a crutch to
| lessen thr memory safety burden.
|
| And their development in the last 15 years is just trying to
| escape the oo cage they were put in.
|
| Something that fixed C++ would have been a godsend in 2004.
| Nowadays... just a nice thing to have.
| einpoklum wrote:
| Well, you did get a whole bunch of fix for C++ in 2011...
| jcelerier wrote:
| What makes you think that these two statements are exclusive?
| googlryas wrote:
| I don't mean to say they are mutually exclusive, merely that
| it takes a very smart person to be able to say both. For most
| people, a language that is 10x more complex than a language
| with ideal simplicity and safety, is too difficult for them
| to understand - or at least too difficult for them to
| understand without putting in years of study and practice,
| something which is not reasonable for most programmers.
| jonex wrote:
| For a class of problems, there's basically two options of
| language to use that would fit the requirements, C++ and Rust.
| While Rust is promising and getting some traction, saying that
| it's the clear winner in all aspects would be a stretch. So
| therefore there's a lot of people who end up with your first
| statement. And given the kinds of problem where it's the best
| tool, a lot of those would end up actually interested in the
| second statement. However, of course most people wouldn't have
| the opportunity to do so. We're lucky that there are people
| that end up with all three like Herb Sutter, IMO, or we'd be
| stuck with 98 semantics... (I guess it would have helped Rust
| getting popular faster though...)
| metadat wrote:
| Looking forward to finding out what kind of feedback and
| discussion this generates. Some of the changes seem to make the
| syntax pointlessly different. /* Proposed "new"
| c++ syntax */ main: () -> int = { cout <<
| "hello world\n"; } // vs. /*
| Classix c++ syntax */ int main() { cout <<
| "hello world\n"; }
|
| The "new" way looks a lot like a copy of the newer Java syntax
| for closures.
| nickhalfasleep wrote:
| The idea is to have a consistent way across many items,
| functions, lambdas, etc...
| Sharlin wrote:
| The "type first" declaration syntax is a source of much wailing
| and gnashing of teeth when it comes to trying to parse C++. See
| the "most vexing parse" [1].
|
| [1] https://en.wikipedia.org/wiki/Most_vexing_parse
| criddell wrote:
| Both versions are supposed to return an int but neither has a
| return statement. Is that not an error?
| e4m2 wrote:
| The main function returns zero implicitly if control flow
| reaches the end without encountering a return statement.
| LeSaucy wrote:
| It wouldn't be C++ without undefined behaviour.
| humanrebar wrote:
| Some of the syntax changes are to support simple LR parsing.
| Ideally cpp2 would have boring grammar descriptions available
| for popular off-the-shelf parser generators. No need to link
| libclang into everything.
| hackingthenews wrote:
| This is explained in the talk he gave. One of the benefits is
| that with new syntax the semantics can change without breaking
| backward compatibility, e.g. [[nodiscard]] can become default
| for all functions written in the new style.
| williamvds wrote:
| From a C/C++ programmer's POV those may look like GOTO labels,
| I agree. The proposed syntax is probably a consequence of a
| modern trend in using := for declaration and assignment.
| x := 5
|
| Where you can optionally insert the type between the colon and
| equals, otherwise it is deduced x : int = 5
| noobermin wrote:
| All the replies are missing something, does cpp2 have goto
| labels? What happened to them.
|
| Unless you now have named loops in modern C++ now this
| removing goto is problematic.
| teo_zero wrote:
| In English, the colon is used to separate a term to its
| definition, so it looks perfectly apt to mark declarations.
|
| Besides, it makes it trivial for text editors to implement
| "go to definition", and many other niceties without a real
| semantic parser.
| thechao wrote:
| I used to code for a language called "Spad" -- originally
| shipped in 1972(?). The syntax: x : t = e
|
| Was called "headform" and was the _only_ syntactic form for
| the whole language. (Expressions used a shunting yard
| algorithm to desugar into a sequence of headform.)
|
| The language included modules, classes, parameterics,
| functions, constraints, ..., whatever.
| SaddledBounding wrote:
| > The proposed syntax is probably a consequence of a modern
| trend...
|
| ML uses `name: type = value`. It came out over a decade
| before C++ and just one year after C.
| cvoss wrote:
| It's not modern at all. Type system notation has been using x
| : T to say "x has type T" for at least 50 years. It's the
| standard in academia, and has existed in real-world
| programming languages since 1971. [0]
|
| [0] https://cstheory.stackexchange.com/questions/43971/why-
| colon...
| forrestthewoods wrote:
| It is an old idea and also a modern trend. Trends come and
| go. It is currently trendy.
|
| 90s fashion is also trendy right now. Which is great
| because a few years ago it was 80. The cycle continues!
| dvratil wrote:
| I don't think this has anything to do with modern trends - :=
| is a formal way of writing assignment (the widely used = is
| actually an equality sign), and has already been present in
| Pascal for decades (and other languages as well).
| Jtsummers wrote:
| https://en.wikipedia.org/wiki/ALGOL_58
|
| ALGOL, the := in programming languages used for assignment
| comes from IAL which became ALGOL 58. It's definitely not a
| modern development. Go reintroduced it to popular
| mainstream languages, sort of. Except they still use = for
| assignment and := is used when it's also declaring a new
| variable.
| rafram wrote:
| I'm not sure I'd := is a "modern trend." Smalltalk had it
| circa 1972, but none of the modern-day hip languages I can
| think of do. Your latter example is a common syntax, but the
| colon is omitted with the type in most languages (TypeScript,
| Rust, etc.).
| charcircuit wrote:
| X being a modern trend does not mean it was not done in the
| past. It doesn't mean that it hasn't trended in the past
| either.
| hota_mazi wrote:
| It's disappointing they would keep that odd << syntax, which
| has always looked weird to me.
|
| Why not take this opportunity to streamline the calling syntax?
| Streams are no different than regular function calls, e.g.
|
| cout.output("hello").output("world\n")
| layer8 wrote:
| You are talking about library API design, not language
| design. A new C++ syntax will not change how functions in the
| standard library are named (e.g. operator<<).
| CyberDildonics wrote:
| That is an operator overload of a library and not built in
| language syntax.
|
| Even so there is now std::format
|
| https://en.cppreference.com/w/cpp/utility/format/format
| hota_mazi wrote:
| Doh, you're absolutely correct.
| oblio wrote:
| The "new" way is basically updated Pascal, which was the right
| way to do it, from back in the 80's.
|
| Similar story with C strings vs Pascal strings, another can of
| worms.
| onedognight wrote:
| It's actually close to the new C++ syntax for functions. Take a
| look at the output C++ in the regression-tests/test-results
| folder: auto main() -> int { cout
| << "hello world\n"; }
|
| The difference between the two is mostly the : and the =. The
| colon is for declarations being written: i :
| int = 0;
|
| Instead of int i = 0;
|
| main is the variable/function above and its type is ()->int and
| it's being assigned, i.e. defined, hence the =. This syntax
| removes a ton of parsing complexity and makes the language more
| regular. Functions are defined and assigned similarly to
| variables.
| dataflow wrote:
| That colon is going to be quite burdensome to type, due to
| the need to hold the Shift key on a line where you otherwise
| might not need to. It might sound silly but I do think little
| things like this can really hinder adoption without people
| necessarily realizing it.
| Merad wrote:
| Meaning no offense but if you aren't exaggerating you might
| want to invest some time in typing lessons. I'm not even
| remotely close to being an expert typist and I spend most
| of the day going back and forth between a C style language
| (C#) and modern style that uses the colon (Typescript). The
| difference needed to type a colon doesn't even register.
| dataflow wrote:
| I write both C++ and Python all the time and I type
| enough underscores and caps all day just fine, thank you.
| The colon doesn't register for me when I'm writing those
| either. When it _did_ register for me was precisely when
| I started designing my own language, attempted to design
| declarations with this exact syntax, played around with
| it, and realized this is a burden I 'd never noticed
| before, and that this was one thing that made languages
| more pleasant to write in.
|
| Think of it like font kerning. Some people notice it,
| some don't, but most people prefer good kerning even if
| they never think about it.
| wyan wrote:
| In many non-US keyboard layouts typing the ";" requires
| holding shift as well, so not sure how bad this issue is in
| actuality.
| hiccuphippo wrote:
| You could just change your keymap if you really need to. I
| used to remap / in my Spanish keyboards because normally it
| is shift+7.
| coliveira wrote:
| Tell this to people using Python. Every function, if, and
| loop has a colon at the end.
| dataflow wrote:
| You misread my comment. I'm not saying "colons are bad",
| I'm saying "excessive holding of keys is bad".
|
| if (cond) { } requires 4 presses of Shift (or 2, if you
| combine them).
|
| if cond: foo requires 1 press of Shift.
|
| I'm not sure what part of my comment makes you believe
| that I think the latter comes out worse than the former.
| If anything, the fewer keypresses probably strongly
| helped Python's success without people necessarily
| realizing it. Moreover, this might very well be one thing
| hindering more widespread adoption of Python's type
| annotations.
|
| You also need to consider how common each construct is. A
| class declaration requiring 20 excessive keystrokes is
| not necessarily worse than a variable declaration
| requiring 1 excessive keystroke.
| [deleted]
| gumby wrote:
| No emacs user would even notice.
| metadat wrote:
| Or Vim and Python users. They type ":" a lot.
| KerrAvon wrote:
| You must not have used Python or classes in C++, where the
| colon is ubiquitous?
|
| Does `{` not require shift on your keyboard?
| dataflow wrote:
| > You must not have used Python or classes in C++, where
| the colon is ubiquitous?
|
| You misread my comment. I'm talking about cases where
| existing prevalent syntax for that construct does NOT
| already require holding Shift. Python is _better_ in this
| respect since ":" requires fewer presses of Shift than
| "{" or "}". This is not the case when you go from "int x
| = 1;" to "x: int = 1;".
|
| Moreover, the inconvenience of going from 1 Shift to 2 is
| not the same as the burden of going from 0 to 1.
| Especially because you can often combine the 2 into 1
| without releasing the modifier key in between.
|
| And furthermore, variable declarations are _far_ more
| common than class or function declarations, so you can 't
| weight them equally.
| kagakuninja wrote:
| No more burdensome than using capitol letters (camel case),
| underscore (snake case), curly braces or quote marks.
|
| Been using Scala for 7 years, and it has never even
| occurred to me this was a "burden".
| uwagar wrote:
| ouch is it just me that feels
|
| int i = 0; // pretty
|
| i : int = 0; // ugly
|
| i will stick to c++03 thank u very much.
| tricky777 wrote:
| the ugly way is easier for the parser on some edge cases.
| https://en.m.wikipedia.org/wiki/Most_vexing_parse
|
| syntax "beauty" is just a matter of how used to it you are
| (excl brainfuck ofcourse). Admitting this, is quite a big
| present one can give to him/her self.
| mgraczyk wrote:
| Most new languages use postfix types. I grew up using C and
| C++, but now that I've learned and use Python with types
| and Typescript, I'm used to and prefer postfix syntax
| uwagar wrote:
| shouldnt it then be?
|
| i: int 0 = ;
| mgraczyk wrote:
| No, it should read grammatically as English.
|
| int x = 0 "There is an integer x with value 0"
|
| x: int = 0 "x is an integer with value 0"
|
| x: int 0 = "x is an integer that is zero valued"
|
| The last one is awkward, the first one is harder to read.
| kagakuninja wrote:
| I have been using C and related languages since 1980.
| Switched to C++, later Java. Then about 7 years ago, I went
| all in on Scala, and have never looked back.
|
| Something like "i: int" is superior (at least in Scala),
| because the type annotation is optional. You can drop it,
| and just say "val i = 42". I believe it simplifies the
| parser as well.
|
| There is a reason many modern languages are adopting the
| style.
| philippejara wrote:
| been a bit since I've touched c++, but is there any reason to
| use trailing return types in that manner aside from solving
| scope issue with decltype on templates? I assumed this was a
| way to write functions to deal with that case and not for
| "regular" functions.
|
| On another note, anything with "->" is just painful to write,
| same thing with the (in his proposal) ":_" instead of "=" for
| function arguments. Just annoying.
| Jtsummers wrote:
| :_ appears to mark it as a generic type parameter, the
| `hello` function in the example ought to be equivalent to
| this straight C++: template<typename T>
| void hello(T msg) { std::cout << "Hello " << msg <<
| "\n"; } hello: (msg: _) = {
| std::cout << "Hello " << msg << "\n"; }
|
| I kind of like this, actually, because so many people I've
| worked with are afraid of templates in C++, but they seem
| to have no trouble with essentially equivalent code using
| generics (in other statically typed languages) or
| dynamically typed languages where it "just works" (until it
| doesn't). Not that we'll be adopting this any time soon,
| but I suspect they'd be more amenable to this form when
| `template` seems to make them quake in their boots.
| gpderetta wrote:
| The syntax: void hello(auto msg){
| ... }
|
| Is legal today (since C++20 IIRC) and it is equivalent to
| your first example.
| philippejara wrote:
| Ah actually missed that, good catch, it does seem to be a
| step forward in regards to dealing with the syntactical
| clunkyness of templates. Now if we could have keyword
| arguments in functions calls without having to deal with
| some kludge...
| mgraczyk wrote:
| You have to use it for lambdas, so using it everywhere
| makes some code more consistent and readable
| alcover wrote:
| Allow me to hijack a little. I'm working on a new language.
|
| Would you people object to ':' for assign and single '=' for
| equality ? int i:42 if i=42 print "ok"
| mkl wrote:
| Maxima does something like this. It's weird to use. I think
| := for assignment makes more sense if you want = for
| equality.
| bhawks wrote:
| Golang uses : to assign in struct initialization and := for
| new variable assignments so there is some prior art.
|
| Practically speaking I find : to be challenging to quickly
| scan out of source visually. In golang this objection is
| muted slightly because struct initialization usually ends
| up being clearly indented by the formatter.
| metadat wrote:
| Why does it need both the keywords "auto" and "int" when
| declaring main()? Just seems extra confusing..
| mgraczyk wrote:
| This is cruft. Without auto it wouldn't be parsed as a
| function declaration
| hardlianotion wrote:
| In that particular case, it looks like he declared and assigned
| a thunk called main. It looks different to me than the
| original-style main.
| zozbot234 wrote:
| > main: () -> int = {
|
| Y U NO fn??!? So close, and yet so obviously wrong.
| duped wrote:
| Why add a keyword when you don't need it?
| [deleted]
| bogdanoff_2 wrote:
| For easier grepping
| duped wrote:
| Use an IDE
| Koshkin wrote:
| fn is no fun
| ivraatiems wrote:
| This is a minor thing, but why is the file extension .cpp2 and
| not .cpf or .cp2 similar? Why make it longer/uglier?
| mhd wrote:
| Sutter might be a bigger name, but I think this has about the
| same chances as Damian Conway's SPECS[1].
|
| [1]:https://users.monash.edu/~damian/papers/HTML/ModestProposal..
| ..
| projektfu wrote:
| Perhaps. But Sutter sits on the committee, and therefore has
| more ability to get these things into the standard.
| WCSTombs wrote:
| From what I gather, the projects have quite different goals.
|
| CppFront:
|
| > My specific goal is to explore the question: Can we make C++
| 10x safer, simpler, and more toolable if C++ had an alternative
| "syntax #2," within which we could be completely free to
| improve semantics by applying 30 years' worth of C++ language
| experience without any backward source compatibility
| constraints?
|
| SPECS:
|
| > We propose an alternative text-based syntactic binding
| (called SPECS) for the existing semantics of the C++ language.
|
| So while SPECS is semantically equivalent to C++ as it is
| today, CppFront isn't bound by that constraint.
|
| Sutter makes this very clear later in the README:
|
| > Important disclaimer: This isn't about 'just a pretty
| syntax,' it's about fixing semantics.
|
| Just to be clear, my intent isn't to diminish Conway's work in
| any way. Both are interesting projects, just with different
| goals.
| lifthrasiir wrote:
| > So while SPECS is semantically equivalent to C++ as it is
| today, CppFront isn't bound by that constraint.
|
| This can be actually seen as cppfront having _less_ chance
| than SPECS.
| zozbot234 wrote:
| CppFront is supposed to be 100% link-compatible with the
| existing C++ ABI. Even if that isn't "semantically
| equivalent" in a strict sense, it's so close that it makes no
| real difference.
| strictfp wrote:
| This sounds very similar to how Jetbrains tried to improve on
| Java but in the end deciding to invent Kotlin; a new language
| with more consise syntax, better defaults, some new features, and
| great interop back and forth with Java.
| rootlocus wrote:
| > great interop back and forth with Java.
|
| That's something all JVM languages share. Not that easy with
| compiled languages unfortunately.
| [deleted]
| jpeter wrote:
| C++ needs a new frontend. Something close to C# / Kotlin
| jiripospisil wrote:
| > We've already been improving C++'s safety and ergonomics with
| every ISO C++ release, but they have been "10%" improvements. We
| haven't been able to do a "10x" improvement primarily _because we
| have to keep 100% syntax backward compatibility_.
|
| You really don't. The vast majority of projects will never change
| the language version they use. Simple projects are simple to fix.
| Remaining large projects have enough resources and expertise to
| do changes across their entire code base - Chromium has recently
| changed more than 15000 instances (in over 8000 files) of using
| raw pointers to using raw_ptr instead in a single pull request
| [0]. How? They wrote a Clang based tool which did it
| automatically [1].
|
| [0] https://chromium-
| review.googlesource.com/c/chromium/src/+/33...
|
| [1]
| https://source.chromium.org/chromium/chromium/src/+/main:too...
| tusharsadhwani wrote:
| Projects can't keep using an old compilers because of security
| patches though. At some point, the old versions are too old to
| keep the security up to date.
|
| A more common example, what if a library that you use stops
| supporting the old version, and the latest compatible release
| of the library has a security vulnerability.
| jiripospisil wrote:
| > Projects can't keep using an old compilers because of
| security patches though. At some point, the old versions are
| too old to keep the security up to date.
|
| I'm talking about using the same language version (standard),
| not compiler version - e.g. the latest Clang still supports
| the C++98 ISO version.
|
| > A more common example, what if a library that you use stops
| supporting the old version, and the latest compatible release
| of the library has a security vulnerability.
|
| You backport the fix or the change library. Nobody said it's
| easy but your project should not hold the entire language
| hostage.
| detaro wrote:
| That doesn't match my professional experience: Many code bases
| iteratively move forward through language versions. They do
| vary in how intensely they drive this, which can lead to vast
| differences across different areas of the code, but that is not
| necessarily bad, but would be an issue with hard breaks.
| lostdog wrote:
| There was a years-long conniption over the Python 2 to 3
| migration. I also believe that it's ok for a language to break
| backwards compatibility once every 40 years, but I completely
| understand why so many language designers are afraid to.
| choeger wrote:
| I seriously wonder why no one did that before (put a context-free
| language in front of C++). Presumably, because of the need for
| modules to get anything beyond trivial code (without modules, one
| would have to use the preprocessor which would intermix old and
| new syntax).
|
| Now, please do it. Context-free syntax is so obviously better
| that it's really an embarrassment, people are _still_ defending
| hacks from decades ago.
|
| And please, for the love of Knuth, someone do it with LaTeX, too.
| dehrmann wrote:
| > I seriously wonder why no one did that before (put a context-
| free language in front of C++)
|
| My guess is either yes, macros, or if you're going to write a
| new language, you can skip C++, output object files, and make
| them compatible at link time.
| saurik wrote:
| https://users.monash.edu/~damian/papers/
|
| Scroll down to "A Modest Proposal: C++ Resyntaxed".
___________________________________________________________________
(page generated 2022-09-17 23:00 UTC)