Thread 106252504

>be c++ committee
>propose reflection for c++26
>add annotations for reflection so you can attach metadata to symbols
>need a new syntax
>[[...]] already used by attributes which can be ignored by the compiler, have to choose something else which cannot be ignored
>somehow choose [[=...]] instead of @... (java), #[...] (rust), [...] (c#)
>RANDOM ASS EQUALS SIGN
>annotations appear AFTER the type/storage specifier and not before like every sane language does
who the fuck writes these proposals and how does c++ consistently manage to design the ugliest syntax for new features ever conceived? do they all have brain damage or something?
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3394r0.html

see coderel from pdf
struct Args {
[[=clap::Help("Name of the person to greet")]]
[[=clap::Short, =clap::Long]]
std::string name;

[[=clap::Help("Number of times to greet")]]
[[=clap::Short, =clap::Long]]
int count = 1;
};

int main(int argc, char** argv) {
Args args = clap::parse(argc, argv);

for (int i = 0; i < args.count; ++i) {
std::cout << "Hello " << args.name << '\n';
}
}

>>106252504 (OP)
They get off on it.

look as long as the crab loses this is still fine

lol does clap stand for command line arguments parsing? thats clever who came up with it

>[[=Annotation]]
>instead of the countless better syntaxes that other languages have already
>@Annotation
>[Annotation]
>#[Annotation]
>Somehow choose [[=Annotation]]
Are sepplesfags all brain damaged? Who in their right mind thinks [[=Annotation]] is an acceptable syntax for literally anything?

Those who do not understand Rust are destined to invent a poor copy of Rust.

>>106252544
They also came up with [](){}

>>106252545
this isnt like rust its better

>>106252561
>[Captures](Params) -> Return { Body }
I see nothing wrong with that syntax. It is as intuitive as can be, unlike the annotations syntax. Java and C# both have syntax like this for lambdas as well. What is the problem with []() -> T {} ?

>>106252504 (OP)
// Declaring a final class

// Java:
final class X {
// ...
}

// C++:
class X final {
// ...
};
// still have a random ass semicolon at the end even though no one uses that stupid C feature for instantiating structs after definition

Not the first time C++ does this retard shit.

c++ is already a disgusting language, why do they keep making it worse? just use c instead

>>106252609
to be fair many headers may rely on that feature since ages ago and removing features is kinda difficult because it breaks shit

>>106252504 (OP)
Nigga?

struct Args {
[[=clap::Help("Name of the person to greet")]]
[[=clap::Short, =clap::Long]]
std::string name;
};

>somehow choose [[=...]] instead of @... or #[...]
>annotations AFTER the type
>brain damage committee

>>106252504 (OP)
>pretending mythical "modern c++" matters, or anyone is going to ever use it (past C++17)
>>106252536
it's a poor attempt at impersonating a popular rust crate. lol.
i considered that you might be joking about just that. but the crate stands for "parser" not "parsing" ;)

>>106252753
>just use the language responsible for half of all of c++'s problems
kys proceduraltranny

>>106252543
second half of >>106253361 was for you

>>106252753
>just use c instead
Literally what problems would downgrading to C and losing literally everything a modern language should have solve?

>>106252504 (OP)
What were they thinking?
>>106252544
>>@Annotation
I know right? Just do that instead.

>>106253393
>choice between poorly named and poorly implemented hash map (C++) or no hash map at all (C)
just use a better language (Java or Rust) at that point

>>106253412
nta.
C has its (narrow) uses, helped by universal availability and being THE system language since forever.
C++ however is never the right choice, when there is choice, which is unfortunately not always the case.

>Cnile boomers still keep ruining C++ with autistic syntax
Can we just burn this language to the ground and start over?
And I don't mean Rust or Herb Sutter's faggot cpp2 which looks like Go if you made it somehow even uglier.
I mean forking C++, throwing out all the retarded syntax, and actually redesigning the standard library to be sane.
Make classes have a consistent naming convention, actually use nested namespaces in std, modules from the start and no header nonsense, and get rid of the Cnile syntax (like int a[5] instead of int[]/int[5] a, etc.)
Not to mention the C++ committee is deliberately gatekept to prevent new ideas from getting in without being previously established. You have to fly to some bum fuck country three times a year to present your proposal, pay thousands of dollars for hotels, pay for attendance, and your proposal is likely to be rejected without backing from large corporations too.

C++ looks more of an intermediate language rather than a language

>>106252504 (OP)
>clap
>derive
>#include <https://raw.githubusercontent.com/bfgroup/Lyra/refs/tags/1.6.1/data/single_include/lyra/lyra.hpp>
lmao, just use rust already

>>106253361
>>106253374
they need to change the name right now

>>106253730
saar we use modules now not include

And Bjarne wonders why everyone is leaving C++ en masse.
>Bjarne got autocorrected to Bharat while typing this

saar, dont fuckin redeem c++ committee you bloody benchod bastard, i poo in the loo

>>106252544
>#[Annotation]
# is already occupied by the preprocessor, sorry.

>>106252504 (OP)
>open-std
>clap
>clap
>clap
>clap
>clap

>>106254648
plap
plap
plap
plap
get pregnant

>>106252504 (OP)
thats a military jet

>>106252561
That, I'm actually ok with.

>>106252504 (OP)
embarrassing

>>106252504 (OP)
>mfw sepplestrannies cant even use their own language
>still using cout instead of println
for (int i = 0; i < args.count; ++i) {
std::println("Hello {}", args.name);
}

literally a self own to not use additions to your own fucking language

this screams autism

Would you guys use metaclasses if/when they come to C++? These look like they would be a game-changing feature.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0707r3.pdf

>>106252504 (OP)
Rust wins again

>>106252504 (OP)
that annotation should be written before the struct
like this

[[=derive]]
struct Point {

>>106253730
can you actually include header from github repo url now?

looking forward to reflection that still can't reflect any shit better than boilerplate macros

>>106252504 (OP)
What's the use case for C++ today since Rust and Javascript exist?

>>106254867
Trade Offer:
>I get:
>>more work
>>retards sperging "you must update to current standard"
>>a limited userbase
>>a reduction of "public:" as though i dont already struct everything
>>no improvement in virtual inheritance
>>some shit macros could do 5 C++ releases ago
>You get: cv-goy points at boomer corp, sorry, "shop" that'll be dead within 2 years
Nah I'm good. I'm sure the retards whose experience is limited to crying over nodejs router lines of code will be impressed by this, though.

>>106255275
ps: in c++20, the latter is just one friend method that does a signed comparison, or in queer terms, "le threeway spaceship operator method."

So, yea, this completely retarded and unasked for in current era. The fact people, utter midwits, are still talking about invented problems goes to show how little they care about fixing or adding genuine improvements to the language. It's always some google pajeet trying to break existing code or some utter schizo syntax of sugar that nobody wants to deal with.

>>106252504 (OP)
C++ fags love their incomprehensive syntax soup. It's already the most unreadable popular language and they just keep adding more of this crap.

I simply refuse to believe this.

By the time it gets implemented, if it's accepted at all, we all will already be dead from AI apocalypse.

>>106252504 (OP)
Does anyone even use all this crap in production? All the professional C++ code I've seen has been the most basic C with classes stuff.

>[[=<>]]
Why do these fucking trannies always end up using horrible symbol combinations that only means something to them? You literally cannot figure out what this means without joining their latest programming cult.

>>106252561
silence of the lambdas?

>>106252504 (OP)
i should write in rust atm. cpp has been a copycat

>>106252609
I used this once in my career

>>106255517
Lol

>>106253361
In 3 years you'll be saying "(past C++20)". You can't escape using the newer version because each "modern" version comes out with blatant issues and shit missing, which at this point I think is done on purpose

>>106252504 (OP)
Tf is this garbage.

>>106253467
if youre gonna completely break every codebase, you might as well actually start from scratch. like zig or odin

Subhumans complaining here have 0 relevant projects who they have full control over and that's the only reason why they're bitching and crying over OPTIONAL new thing that doesn't affect them. They get no say in any project, their opinion is WORTHLESS, and 4chan is the last place where they schizophrenic comments won't be deleted on sight.

>>106252504 (OP)
who cares about these new features. compilers will first support them in the y ear 2065, if we are lucky

>>106254867
>would be a game-changing feature.
>>106255947
>In 3 years you'll be saying "(past C++20)".
C++17 is the (soft) cut for where the language was still a primary choice for new projects, when the "modern C++" rolling meme wasn't fully exposed yet.
Those days are long gone. There is no game to change the outcome of, because the last "game" was already played, C++ lost it, and everyone accepted the defeat except bureaucrat maister Bjarne and a few others in his super tiny fan club. lol.

uwu operator when

>>106256022
>zig
>odin
memelangs

>>106252504 (OP)
To be fair, C++ grammars are totally buck broken. It's literally impossible to parse C++ deterministically (unlike rust).

what durgajeet came up with this shit

>>106257588
std::string operator ""_uwu(const char*); // do it anon

>>106256150
>[[=Annotation]] is a good syntax, actually
Kill yourself Wyatt Childers.

>>106257648
If you don't like it, simply don't include it in your project, nobody cares.

>>106252504 (OP)
LMAO
and here I thought that the JS spec is shit, jfc

>>106257695
You could say that, if JS had one.

>>106257699
https://ecma-international.org/publications-and-standards/standards/ecma-262/

What is WRONG with C++?

>>106257997
this lil nigga wins again

>>106258041
>spamming if err != nil is good
are you perhaps by chance indian
do you get paid 5 rupees for every line you write

>>106258051
seethe more, durgajeet

>>106258062
>gojeet projecting again
>saar, you are the indian not me

at this point they're just adding whatever proposals just for the sake of adding new features for no reason if they're cheap enough to implement. like most of c++ developers use 10% of the language features.

>>106252504 (OP)
First I thought it was rust but then I noticed that it is readable

>>106260011
Method chaining is good, static methods are good
std::to_string() should be String::to_string()

>>106260011
>random bit shifts out of nowhere
>readable

it's interesting that a few years ago if someone wrote C++11 or even 17 in their CV I'd consider them capable and up-to-date
if they now write C++23 I'd consider them mentally ill

>>106260416
At this point they just add whatever shit looks quirky or out of the ordinary to look hip and relevant, all while not merging useful long-needed almost trivial features like std::net and std::process.

>>106260416
>>106260486
Would you be sad or happy if they merged pattern matching into the language?

>>106252504 (OP)
>[[=clap::Help("Name of the person to greet")]]
I got the clap just seeing this syntax.

>>106260724
I wouldn't give a shit and I'd fire anyone who insisted on using it in our boomer codebase

dropping C++ for Circle when?

There is no c++ standard beyond c++11.

>>106260372
You know what, I think you're right. The more time I spend looking at it, the less sense it makes. It's not abstracting anything away, it's just a straight up misdirection, a Kansas City shuffle.

>>106257459
>C++17 is the (soft) cut for where the language was still a primary choice for new projects, when the "modern C++" rolling meme wasn't fully exposed yet.
>Those days are long gone. There is no game to change the outcome of, because the last "game" was already played, C++ lost it, and everyone accepted the defeat except bureaucrat maister Bjarne and a few others in his super tiny fan club. lol.
Elaborate please? Do you think that C++ is dying?

>>106252504 (OP)
THE
JEWS
ARE
TRYING
TO
DESTROY
C
PLUS
PLUS !!!!!!!!!!!!!!!!!!!!!!!!!!!!!

>>106253467
>Can we just burn this language to the ground and start over?
we did it's called java

>>106260903
Looks like it needs to burn again.

>>106260784
What would you most like to have in C++? Or do you prefer Rust or some other language?

>>106260802
>Circle
Not even actively developed, and the compiler is closed-source, with any plans for momentum, ecosystem growth or business apparently having failed. https://youtube.com/watch?v=XZ3w_jec1v8

>Carbon
Parts of it are very poorly designed and engineered. No MVP yet.
>The language is expected to have an experimental MVP version 0.1 in late 2026 at the earliest

In the end all people need is c with classes and data structures somewhere in the standard library.

>>106260875
More like old language is old, and new languages disappoint in a lot of ways and some even waste time playing dirty instead of fixing their shit.

the jews are all in on go and rust

the sepples committee subverts itself just fine

>>106252504 (OP)
They are fully aware that no one actually cares anymore so they are spasing out. C++ is a dead language and the committee is fully to blame

>>106260875
I was not Aware that Bjarne is kosher.

>>106261060
there is no such thing as accidents incompetence or second order effects when bad thing happens its intentional sabotage and the end goal is to tear down all the statues

>>106261069
There are lots of Jews in the C++ community. Though whatever ones' thoughts are, who is or is not there does not matter all that much, due to ISO. ISO is dysfunctional, and can be gamed by companies and groups, but it is still difficult for any one group to maintain control. And C++ has open source compilers.

Rust also has an open source compiler. But no ISO, instead a foundation, sponsors, Zulip and Discord groups, project leaders, and hordes of zealots. Rust could be forked, but contrary to the Foundation's very active and perception-warping fundraisers, it isn't clear whether it is even worth doing so due to all of Rust's issues.

The worst case is C++ dying, Rust revealing itself to be bad technically and difficult to fix, and no other worthy successor languages gaining momentum.

Best case is if C++ does not die (in contrast to those that seem to hope to kill off the competition (namely C++) so they don't have pressure on them to innovate and fix their shit), Rust having its shit fixed, and promising languages appearing.

>>106261221
if c++ dies we will just all write in javascript

>>106261221
>Rust also has an open source compiler.
if you cant compile it its not open source

>>106261110
Maybe he's shabbos goy?

>>106261248
Cute joke. How many Javascript runtimes are written in C++? Most?
https://en.wikipedia.org/wiki/List_of_JavaScript_engines

>>106261261
>Compile compiler for new language in compiler that was written in C

>>106261261
Are you saying that rustc cannot be compiled independently? I thought they even had bootstrapping.

>>106261273
The sooner we start compiling our JS runtimes in JS the better.

>>106260985
a lot of parts would be fine leaving in boomer C++, since they heavily rely on Qt and other C++ specific frameworks that have their own quirks but are stable and mature
others would benefit from being written in a GC'd language, they are not really cpu intensive and work as glue between systems
for very small, performance-intensive parts I'd consider Rust, but as a known trade off in complexity/build time, which we'd need to pay for

>>106261275
>The auto-self-embedding malware detects the construction of a new compiler and does the needful

>>106261287
they dont go try it you need to already have the compiler to compile the compiler

>>106261292
>GC'd language
Braindead.

>>106261117
Depends on the specific case, as usual. Sometimes accidents happen, sometimes perpetrators try to mask things as accidents, for instance a murderer hiding the bodies.

>>106261333
Or a Rust programmer aliasing GCC.

>>106261289
What will run on the hardware, funny man? Or is it turtles all the way down?

>>106261344
Please elucidate.

>>106261306
I doubt you.

>>106261261
>this retard again
guix proves you wrong.
https://guix.gnu.org/en/blog/2018/bootstrapping-rust/

https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
https://bpb-us-e1.wpmucdn.com/sites.gatech.edu/dist/a/2878/files/2022/10/OSSI-Final-Report-3.pdf
https://archive.ph/uLiWX
https://archive.ph/rESxe
https://lkml.org/lkml/2025/2/6/1292

>>106252545
Those who do not understand C++/Haskell are destined to invent a poor copy of C++/Haskell.

Then Rust born.

>>106261368
I believe you are a pajeet.
The "software" "runs" on the "hardware."

>>106261573
>Then Rust born.
nice one rajeesh

>>106261480
That's a lot of links that I ain't gonna click.

>>106252536
Isn't Rust dead anyway with its engineers jumping ship?

>>106261069
You think that Bjarne needs any external help to destroy C++? lmao

>>106261626
61 seconds anon, 61

>>106260856
as an evolving language, C++ is already dead.
but languages don't just die overnight. they just start to lose slowly adoption wise to other languages.
C++ is on that slow death path already for some time now. the only real attempts to salvage it, since nocoder bjarne is useless, is through "C++ successor" projects like carbon.
but with the emergence of languages like Rust, the train has simply left the station already. future system languages will look more like rust than C++. programming linguists are experimenting with things like effect systems, while C++ at its core is till an OOP language from the 70s/80s that doesn't even have sum types, let alone offer, as an example, any kind of concurrency safety.

>>106261595
>engineers jumping ship
Who?

>>106261840
I misremembered how it went but this was it. I don't actually know how vital those two are, I just like doomposting

>>106261665
Do you think that affine/linear type systems will one day be treated as an unremarkable everyday programming thing that everyone is expected to understand, the way recursion and generics are today?

>>106261916
Contributors to large FOSS projects like compiler or Linux generally have day jobs. Only core team is actually hired and these guys are not part of it.

>>106262019
Although my doomposting is ruined, I actually like using Rust so that's good news.

>>106261916
>In related news

>>106262019
>Contributors to large FOSS projects like compiler or Linux generally have day jobs
at the nsa

>>106262140
wtf nooooo ;_;

>>106262474
The door literally rusted at its gears.

>>106254678
printf(3) has been around since 1838 and C++ is supposed to be a superset of C anyways, so there is no reason to reinvent the wheel TWICE.

>>106258071
this site is actually just so retarded ; you see someone you disagree with and both of you just go

>you're indian!!!
>>no you!!!!

being racist must be the strongest form of mental retardation ever witnessed.

>>106263005
No shit Sherlock. Being a /pol/tard is the surest sign of stupidity.

>>106263005
>He hasn't detected the shill <> counter-shill gambit
Get with the times, gramps.
"Every (false) accusation is an admission."

>>106263110
Two weeks to containment!

>>106252609
>no one uses that stupid C feature
Backward compatibility makes this language stand for 3 (three) decades (*10 years) already

>>106261665
>C++ at its core is till an OOP language from the 70s/80s that doesn't even have sum types
The fun part is that Java does have sum types, so it's clearly not impossible to have them with OOP. (The syntax is hellishly verbose, but it's Java so that's expected.)

>>106261936
people from engineering backgrounds, not CS ones, understand languages like rust just fine already, without having to study type theory or category theory or whatever.
so i guess the answer will always depend on the languages involved, more than the theory behind them, as long long as the complexity tax of used/applied theory doesn't reach farcical levels.

>>106263005
considering 80%+ of this sub is jeet (90%+ at the time of day the two comments were posted). problematically speaking, they were both right. so you don't need to kvetch about it this hard, even if you happen to be a jeet yourself.
jeet is not a race anyway. jeetiness is a specific socio-cultural socio-relegious socio-political reality of post-colonial india.

>>106260903
I would use Java if it gave me direct memory management and smart pointers.

>>106253467
just use rust at that point

>>106262968
printf sucks
If it were like Java printf I might reconsider

>>106252561
that one's fine

>>106263561
explain pinning, interior mutability, unsafe, etc.

>>106265765
>pinning
address of value doesn't move without user's knowledge. if its at 0xabcdef1234567890, it stays there.
>interior mutability
mutability without &mut, where synchronization is done at run-time with high-level constructs built on top of atomics.
>unsafe
using raw pointers and other code defined/exposed as unsafe, including ffi.
-----
why would any of this require type/category theory knowledge?

>>106253467
What are your cross-language compatibility goals with C, C++, and other languages?

There are huge numbers of language design decisions to be made, and design and implementation work to be done in libraries and compilers and tools, and such. Who will do all that work? How will you avoid making new or old mistakes? How will you ensure the language will constitute a coherent, useful whole? How will you gain momentum? How will it be funded? How will it be organized?

Circle was interesting, but closed-source compiler and other decisions may have been less good.

Carbon is delayed a lot, and some of the design decisions there are just straight up bad and careless, like them not even doing their most basic homework or research. But huge amounts of research and lots of engineering work is often required even for small parts of a programming language. Is Carbon ready for contributions? What organization will they have? Will it be similar to Rust's development organization, with lots of activity on Github, just under the control of Google?

Modules in C++ apparently have issues. Retrofitting a module system into a language was probably never going to be easy, especially a systems language like C++. And modules were probably forced through without proper reference implementations to get the ball rolling, instead of being perpetually delayed for even more decades. But the core designers of modules may not have been as honest and competent as one could have hoped for. Then again, a lot of C++ language research and development is done through volunteered work, and thus completely underpaid.

JVM has Java, Kotlin, Clojure and Scala, and they can call each other. Could something like that have been done for C++?

>>106265825
Cool, now explain all the rules for them. If you even can, for are all the rules even defined for all that?

A more honest attempt than yours:

https://lwn.net/Articles/1030517/

>Pinning continues to be the most difficult aspect of Rust to understand

When will Rustaceans ever begin to be honest?

>>106265825
>>106265942
Oh hey

https://blog.yoshuawuyts.com/why-pin/
>WHY `PIN` IS A PART OF TRAIT SIGNATURES (AND WHY THAT'S A PROBLEM)
>— 2024-10-15

https://blog.yoshuawuyts.com/placing-arguments/
>Which is important, because we don’t want to add yet another axis to the language, locking out address-sensitive types from being used with existing traits and functions. We’re already suffering through the bifurcation Pin has introduced 1, and I don’t think we should go through this again for self-referential types.
>
>1. And no, unfortunately the “pin ergonomics” experiment won’t do anything to resolve this problem. I think it’s a shame we’re not taking this problem more seriously, because this kind of incompatibility affects the language in ways that extend far beyond syntax and conveniences.

>>106263665
>sub

go back to the orange website ; your summer vacation is almost over !

>>106256150
>OPTIONAL
because the average sepples compiler wasn't slow enough to begin with, they haaaave to add more syntax.

>>106266337
>anon uses r*ddit lingo by mistake
>jeet decides to outtard with "orange website"
can't make this shit up

>>106266507
>>anon uses r*ddit lingo by mistake

>>106266042
> TRAIT SIGNATURES
What is a ‘trait’ and why does it need to be signed.
Sounds like a trait is just similar to an interface

C++ has function prototypes, like C does, for traits.
But C++ has name mangling which is like a signature.
So that’s been around forever.

>>106266862
Traits are neat, I am guessing, related to Scala's implicits and Haskell's type classes. They might have the same coherence requirement as Haskell's type classes. That may be related to the orphan rule in Rust, which deals with an annoying issue in Rust, somewhat shared with Haskell.

Scala's implicits do not have that issue.

Ocaml has research into modular implicits, inspired by Haskell and Scala, though that may have been languishing for years.

Traits in Rust might be dealing with ad-hoc polymorphism, similar to overloading, but constitutes a different approach.

One reason why you might want good support for ad-hoc polymorphism can be seen from Ocaml. In Ocaml, you add integers like this:

3 + 4


but you add floating-point numbers like this

3.4 +. 5.1


Notice how they do not use the same operator for addition. "+" and "+.".

+
int -> int -> int

+.
float -> float -> float


Similar to how C does not have operator overloading, except C has operator overloading hard-baked into the language for some of its types. C users cannot define new operator overloading, unlike C++. Different trade-offs.

>>106254867
kek that interface feature is straight up Delphi interfaces minus the implicit IUnknown support. Only took them 30 years to catch up.

>>106261573
Another ESL seething about Rust

Where’s my AIX xlc bros at?
I’m thinking we need a std::type::char24_t though, for when you’re feeling superior to Microsoft but don’t want to appear as bloated as IBM.

>>106265765
NTA
Borrowing something prevents moving it as it would invalidate a reference in something else, pinning prevents moving as it would invalidate a reference in itself. The purpose is having self-referential struct. The most common form of a self-referential structs are fhe state machines generated from an async function, which hold a fixed stack required to execute it which holds the call stack it last was awaited in. Call stack with functions that take references.
Mutable and immutable references are just named that for simplicity, the actual real constraint is that you can have an either one mutable ref xor multiple immutable refs, xor nothing. So mutable reference is actually a unique reference and immutable ref is actually a shared ref. Without interior mutablity that uniqueness concept overlaps with mutability. But with interior mutability you can turn shared (immutable) acess to a value into unique (mutable) acess to an underlying (interior) value. You do this with a synchronization mechanism to enforces that uniqueness, like RefCell or Mutex
Unsafe let's you call do unsafe things. Unsafe things are things comoiler can't verify are safe (have no possible UB). That doesn't mean they are "bad", just beyond what the compiler can verify. But in most cases, there is some way to verify it, which you the programmer know. So you implement a "safe interface over unsafe", where safe code calls a safe function that can be unsafe, your code verifies whether it's ok to do it, if not you error out, if yes you call the proper unsafe function.
etc. means et cetera

>>106254867
Interface part looks cool, but C++ 20 already has operator<=>() = default for comparison function autogeneration.

>>106261665
>it's another clueless retard spouting buzzwords he doesn't understand episode

C++ is just an MIT hivemind, no real software is written in it

>>106267907
To be fair, std::variant has some drawbacks, and C++ does not have good support for pattern matching yet. There were two pattern matching proposals for C++26, but they weren't mature enough, and were rejected. I expect that we will have pattern matching for C++29, or at least a whitepaper for it.

>>106267907
>quoting random booktard cope as evidence
lmao

>>106268200
Or they'll use The standard way™ to introduce new functionality: take a perfectly functional third-party library and reimplement an arbitrary part of it (yes, I'm still exasperated about libfmt).
https://github.com/BowenFu/matchit.cpp

>>106260856
>Do you think that C++ is dying?
yee

>>106268222
You lost. Rust lost.

>>106255144
>NNpbp
This.

>>106268269
Kek, cnile resorts to quoting a nocoder jeet to hide his inner cope. Lmao.

>>106268376
Insufferable underage community checks out.

>>106268269
>look at this tweet
How about no

>>106268254
That library has not had updates for years, no chance.

>>106268269
>>106268613
>look at this tweet

>>106268269
saaar i dont know anything about programming but this tweet agrees with my biases so please refer to it as my argument saaaaaaar

>>106269286
>seething

>>106268912
Why post a fake screenshot?

https://github.com/systemd/systemd/issues/18767#issuecomment-784570324

Cniles are getting really desperate.

>>106265825
I don't understand why people are so caught up in this.
I'd say pinning is special cased only because valid uses of it require a lot of manual bullshit that's technically dangerous if you don't pay attention.

Most times I care about pinning insofar that it actually hurts me is projection of the pin and only because the existing macros on crates.io really aren't helpful for more annoying cross-module code.

>>106252545
Rust niggers should all hang themselves.

>>106268269
Amazing tweet.

There already exists 3 decent syntaxes for annotations in other languages, @[], #[], [], . Why did they have to choose the non existing worst one?

>>106269500
It's literally a repost from 4chan

>>106269485
Pinning is just like a C++ class that has move and copy constructors and assignments disabled.

>>106269507
They don't like to admit they are just copying Rust at this point.

>>106269507
The best part is, the proposal mentions attributes [[Attribute]] but NEVER discusses why they chose this [[=Annotation]] syntax over literally ANY other syntax, like @Annotation.

>>106269555
I wish they would copy Java instead. Java got everything right.

>>106260778
why couldn't these be a specialisation on comments? this shit is literally documentation stuff, why is it in the language specs itself? wtf is this dynamic language crap?

>>106269507
I don’t like any of those, I would have preferred a keyword. I’m ok with the proposed syntax because at least the chosen weird character (=) is inside the brackets.

>>106269691
>I prefer random bullshit because everything else hurts my feelings.

>>106269625
>java got everything right
>lambdas are classes

>>106269691
metaattribute deprecated metaattribute maybe_unused struct metadata derive Foo {
metadata clap::Help("help message") int value metaattribute indeterminate;
}

Kek

>>106268269
Also
>No compile-time reflection
https://news.ycombinator.com/item?id=36101501 the guy that suggested it got bullied out of rust

>>106269786
Cniles will read this and say this is a good use of keywords unlike Java public static void main(String[] args), while simultaneously claiming their syntax soup [[=&&££€}*|£~##Pajeet++=#%%憂鬱あらZ]]*Annotation is good use of special characters, and Java @Annotation is bad

>>106269700
>Function is bad actually
>just use function pointers, saar
No.

>>106252504 (OP)
Yeah I'm just gonna keep writing C++11.

>>106270760
>#include good
kys

>>106252504 (OP)
Honestly, they should just start from scratch.
And no, I'm not arguing for throwing away all the existing C++ code, just make it a requirement for the new language for there to exist an automated tool converting C++ code into new language code.
>but that way you would simply reinvent C++
Just put a ton of lints and warnings into this new language:
>while technically legal, you should be doing it this way etc...
Overtime everything would be slowly translated into a sane programming language and those libraries that wouldn't likely shouldn't be used anyway due to being unmaintained.

>>106270927
>>106265890
Ideally I think it should be accomplished the same way with Java and Kotlin.
You would not be able to write old C++ and new C++ in the same source file, but new C++ would be able to include an old C++ header with #include_old, and import an old C++ module with #import_old (just an idea, obviously if you have a better idea throw it around). I would like if the C preprocessor was invoked as little as possible, and we could instead have Rust-style macros.
Ideally new C++ should have no headers or includes at all and be all modules.

>>106271158
aka carbon

>>106271284
but i dont like carbon, it has gay nulang syntax and its vaporware

>>106271284
>var name: type
nope

>>106271299
>>106271308
syntax isnt final make an issue on github be sure to use the word gay

>>106269700
What's wrong with that? The storage for them needs to be somewhere. Given the class abstraction gives you a data + vtable already, it seems logical lambdas in Java would just be anonymous classes.

>>106271321
yeah I'll do that, after all google is known to listen to people

>>106270872
find something that isn't just 'treat everything as a single translation unit', because C's #include has proven to scale way better than the alternatives.

>>106271158
i second this, though rust-style macros (especially proc macros) require A LOT of work for compiler implementers (almost unrealistic to expects implementers to catch up on this).
But if you want rust-style macros, that means forcing standardized tokenization across all compilers, which might benefit all tooling, but might take a long time to do. Even rust still hasn't finished implementing all the features originally intended for macros/proc macros.

>>106269700
lambda have their own states and can mutate it on subsequent invocations, this matches well with java's classes. In C++ (though not required by the standard), I've always seen lambda being implemented as structs, where the captured variables are members of that struct, thus your final lambda function is just an instance of that struct, which overrides operator()

>>106270721
>>106252544
The `@Annotation` syntax cannot work on a lexing level, the paper goes in detail over this, but it's hard to properly lex it due to annotations being compile-time expressions, since you can nest annotations, it makes the grammar much harder to parse. Also `@` is not a reserved token in C++, thus using it would mess with already well-established toolings and compilers. Also, on the offchance that annotations be exportable someday, the `@` is an illegal identifier for ELF, PE, and MACH-O

>>106267548
we need to destroy ucs-4/ucs-2, they have no real purpose now that graphemes variations exists. Nowadays, a single codepoint in ucs-4 can't reliably represent a visual character.

>>106271957
@ is reserved as of C++26, and @ is mentioned a grand total of 0 times in that document

>>106268912
>>106269465
Samefag.

>>106267789
Cool, now explain all the rules for them.

>>106269485
>>106269538

>>106265942
>>106266042

>>106272869
You lost cnile, Rust won.

>>106270082
I think the major parties involved were all generally bad, including JeanHeyd Meneide, the guy that got disinvited to hold the keynote. He portrayed the existing system and people involved in it like this:

> that entire shadow world that’s powering the most elegant Rust code starts with a single crate maintained and propelled forward by David Tolnay and his devout helpers, poetically named syn.
>The syn crate (said like the first part of the word “syntax” and exactly like the word “sin”) is the Big Mover and Shaker of Rust.
>Others new to Rust but well-aged in many programming languages — save for the older Lisp veterans — would scoff. If we suggested implementing a C frontend out of token parsing in preprocessor for C, we would be laughed out of the room for even wanting a preprocessor that powerful. But, in this brave new Rust world, not only is Rust’s preprocessor theoretically powerful enough to do that work as an academic on-paper exercise, it is also in-practice exactly that powerful.

>It bought a serious amount of time for the language designers and the numerous compiler engineers to focus on other parts of Rust, while use cases involving generating code and similar could be wrapped up in (proc) macros.

Just search for "toln" or "syn " in this:
https://soasis.org/posts/a-mirror-for-rust-a-plan-for-generic-compile-time-introspection-in-rust/

He glazes David Tolnay elsewhere, but the silly tone (introwospection) on a subject that many people put a lot of effort and time into was probably not the best of moves. Tolnay's possible reason and possible reaction (there is not consensus on who did what in that whole affair) was possibly not right either, but it smells like power moves, politics and manipulations all around.

>>106270082
>>106273246
JeanHeyd Meneide also got #embed into C++ and C, but first also proposed std::embed and other things, went through several revisions in C++, went to C, more work, got accepted, went back to C++, more work, and then got #embed accepted into C++. Unlike what some claim, that JeanHeyd Meneide was not treated properly by the ISO C++ process, I suspect the extra revisions and work helped the proposal a lot regarding overall quality and being suitable for inclusion. For instance, not including std::embed might have been very good, and I am not sure why it was proposed initially.

>>106271399
I do see some contributions here and there on the Insights tab on their Github. But they also redirect some discussions to their Discord server.

>>106273011
Why not care about the software development community being healthy? Fix the shit in your language, Rustacean.

>>106273011
nobody fucking uses it

eta on c++ dying out?

>>106274520
Already happened, 2020 in Prague

>>106272932
He already answered you though. It's just something that can't be moved.

>>106273681
Says Increasingly nervous man (who will never be a woman).