[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: truck-kun.jpg (135 KB, 1832x1372)
135 KB
135 KB JPG
You got hit by truck-kun and got isekai'd to 1972 in the body of Dennis Ritchie. What changes do you make to C before it becomes the default for all systems programming?

I'll go first:
- Make all optimizations opt-in instead of some opt-out e.g. replace 'volatile' with something like 'cached' to be consistent with keywords like 'restrict'
- Clearer syntax: remove if line statements, better pointer and array declaration, maybe syntax closer to JS/Go/Rust with let and fn/func, postfix dereference
- Modules instead of headers, accessibility modifiers instead of dll macros
- Make stdint.h the default with i8, i16, u16, etc
- Add block expressions and a defer keyword, make return keyword optional at end of a block
- Rename typedef to type, make it use an equal sign, allow removing the rvalue to make symbol types that can be used instead of void pointers in public facing APIs
- Remove null terminated strings from stdc lib
>>
>>106621684
>Add block expressions and a defer keyword, make return keyword optional at end of a block
One of the most obnoxious misfeatures of Rust

>replace 'volatile' with something like 'cached'
So you want to add "cached" to almost every variable declaration? How is that good

>Make stdint.h the default with i8, i16, u16, etc
8-bit bytes were by no means guaranteed in 1972. The very first platform C got ported to, Honeywell 6000, was 18 bit with 36-bit words

Some of your suggestions seem like you don't really appreciate the difficulty of fitting a compiler and getting stuff done on a PDP-11/20. The first C compiler to be written in C had almost as many lines of assembly as C, which was typical at the time.
This includes the suggestion to get rid of null terminated strings
>>
>>106621684
I also want to watch truck kun. Where is this form? Please tell me so I too can stare him intensely.
>>
add all the nicer javascript syntaxes like yield, ..., etc
less stupid cnigger pointer and null termination obsession with the string
basic classes but without operator overloading support
>>
compilation warnings about unused/hanging mem allocs
>>
>>106621684
i'd just port pascal and call it a day
>>
>>106621684
struct Foo; // structs can now be forward declared and it now actually works


int main(void) {
struct Foo memb1 = {0, 1, 2};

// dot operator is no longer used to access struct's member fields
// memb1.x = 3; <-- ERROR

// arrow operator is used for both struct pointers and non pointers
memb1->x = 3;

struct Foo memb2 = {9, 8, 7};

// dot operator is now used to call a priv method (can be stacked, called left to right)
// the result is implicitly returned to tha variable that is calling (memb1 = memb1.func())
memb1.addOne().subtractFields(memb2);

// memb1 fields have now values of {-8, -6, -4} while memb2 remains unchanged

return 0;
}


struct Foo {
int x;
int y;
int z;

// struct definitions can now store function delcarations
// introduce 'priv' keyword as a function type storage modifier
// 'priv' indicates that this function prototype is used:
// static struct Foo addOne(struct Foo memb, ...);
// implicitly returns a member and implicitly takes a member as the first argument
// if a pointer is passed it's dereferenced automatically
priv addOne(void); // void in this case indicates that only the implicit argument is being taken
priv subtractFields(struct Foo memb); // takes two arguments (the first one is implicit)
};


// priv functions can be defined in two ways - explicitly or implicitly

// explicit definition has an explicit type (no priv keyword)
// which obiously makes it possible to call it directly (memb = addOne(memb))
static struct Foo addOne(struct Foo memb) {
memb->x += 1;
memb->y += 1;
memb->y += 1;
return memb;
}
>>
>>106621684
>What changes do you make to C before it becomes the default for all systems programming?
but anon
it already is the default
>>
>>106622319
// implicit definition goes into an impl block ('impl' keyword introduced)

impl Foo { // functins in this block can only be called via the dot operator
// in an impl block the 'priv' keyword is used
priv addOne(void) {
// in a priv functions the fields are accessible automatically (no need for arrow accessor)
x += 1;
y += 1;
z += 1;
// no explicit return;
}

priv subtractFields(struct Foo memb) {
x -= memb->x;
y -= memb->y;
z -= memb->z;
}
}


usecase? I don't know
>>
>>106621684
> replace 'volatile' with 'cached'
#define volatile cached
.. done.
> with let and fn/func, postfix dereference
C has a parser with lookahead and lookbehind, doesn't need that shit, why add shit you don't need. The parser is supposed to work for *you* .. not you working for the parser, like in 'go' and 'typescript' and probably rust (that's a case where you're working for the type system)
> modules instead of headers, accessibility modifiers
Are you making a Tools.h++ library for sale? I will blow-away your accessibility modifiers and rape your private member variables directly while deleting your getters and sett... ahem... "accessors" and "mutators"
> stdint.h the default with i8, i16, u16, etc.
Yeah, maybe. One thing is for sure, 'int' should have been 64-bit. Only one compiler got that right.
When we get 128-bit processors, complain until they make 'int' 128-bit. It's the way it was supposed to be.
> block expressions and a defer keyword
what a goddamn mess that would be. MS fakes lambdas anyway... it just makes a random-named function somewhere.
use the macro processor and make a defer with, say, setjump()/longjump() and perhaps alloca().
.. done
> null terminated strings from stdc lib
why? dope vectors in arrays pre-date C. Maybe you'd like to work on a wchar_t system.
>>
>>106621684
A portable, standards-defined take on inline assembly. Other than that, wouldn't touch a thing.
>>
>>106622402
>#define volatile cached
absolute retard
>>
>>106622327
> impl
Java nonsense.
You don't need an impl anything, because *everything* should be an impl otherwise you're not working and just screwing around. Get back to work.
>>
>>106622413
> in-line assembly standardized
That's one I can get behind. The gcc one is terrible, and clang's just about killed me.
The Microsoft VC in line was acceptable until they *fucking removed it* now I get home and my fingers are sore from typing thousands of lines of intrinsic names.
Oh, and would someone please BAN AT&T syntax? It's retarded (unless you're programming on a RSX-11 system running on a PDP or VAX)
>>
I would keep C but modify it just a bit to allow reccursion without stack exploding
>>
>>106622465
A lot of modern compilers will optimize tail calls into (essentially) goto operations if you use -O3 on gcc, for example, it will do it (or try).
Trust but verify.

Scheme *guarantees* it so you don't have to look at the assembly or run it through tests to check the stack activity.
>>
>>106621684
You are describing Pascal, it had all that in the late 60s.
>>
>>106621863
>One of the most obnoxious misfeatures of Rust
The optional return statement is necessary for block expressions. Adding block expressions/removing single line if statements allows for defining defer to act at the end of a block (so it's clear that all defer statements are static entities).

>So you want to add "cached" to almost every variable declaration? How is that good
You have to add "restrict" to every pointer declaration, what's the problem? The point is to be consistent about optimizations that the writer may not be thinking about.
If a bug appears because you forgot to mark something "volatile", it's worse than the lost performance from not marking something "cached". This is more relevant to API programming.
I really think C shouldn't be used for anything other than cross language libraries and embedded programming.

>8-bit bytes were by no means guaranteed in 1972. The very first platform C got ported to, Honeywell 6000, was 18 bit with 36-bit words
Oh, that's weird.

>impl Foo { // functins in this block can only be called via the dot operator
No, I don't want C to be object oriented (there's better languages like Rust/C# for that).
I use C to write libraries that can have binding to other languages, I don't want to deal with name mangling of methods.
Introducing modules would be tough enough.

>what a goddamn mess that would be. MS fakes lambdas anyway... it just makes a random-named function somewhere.
We might be getting defer eventually:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2542.pdf

>A portable, standards-defined take on inline assembly.
I would like that.
>>
>>106621684
first of all I'd masturbate furiously, naked in front of a mirror. then I'd consider some options.
>>
>>106621684
It's a solved problem. I just turn it into Odin.
>>
>>106623461
>If a bug appears because you forgot to mark something "volatile"
Memory accesses are volatile, not variables. Using volatile for variables is one of C's mistakes.
>>
>>106621684
anything you can suggest is already done much better in Rust or C++. Just let C die already.
embedded? Rust since no_std is actually realistic
anything else? pick the ecosystem that works for your project: Rust, C++.
simple as.
>>
File: zero-cost.png (281 KB, 900x966)
281 KB
281 KB PNG
>>106624106
>>
File: rust-security.jpg (181 KB, 1793x1179)
181 KB
181 KB JPG
>>106624106
Let the cope loop commence. Every time this gets posted, corporations and the Rust Foundation waste funds on compute. :^)
>>
>>106624130
>>106624145
what does this have to do with my post?
OP wants to "fix" C (which isn't possible) and wants features it will never have. Rust does them, C++ is already a major uplift over C.
Your post is just flamebait noise with no value. please stop (You)ing and grow a brain moran.
>>
>>106624167
If Rust "fixed" anything with C, how come it produces software slower and more vulnerable than C?
>>
>>106624191
Not to mention uglier, harder to read and way more tedious to develop according to most of the people who ever tried it.
>>
>>106622488
>will optimize tail calls
it's not required though. that's the big problem. no guarantees means trouble.
>>
>>106622303
>Pascal
Indy Project still uses way out of support OpenSSL 1.0.2 and other shit. I can't fathom wanting to get into the crusty old shitshow that is turn-of-the-century Pascal shitware. IDK why people think it was some great uplift when C++ heemed it so hard.
>>
>>106623364
>You are describing Pascal, it had all that in the late 60s.
Too bad it lacked niceties like dynamic arrays or the ability to write a sort function without hard-coding the array size in its signature. kek
>>
>>106622465
>allow reccursion without stack exploding
allocate a big chunk of memory and swap the stack pointer with it
>>
>>106624253
Pascal also had a hard-on for strict structural programming because early return = goto = bad. it's a meme language spawned from the tards who made shit like algol
>>
>>106624073
Oh, good point. But what would the syntax for volatile memory accesses look like?

>>106624106
Dude, none of this stuff is going to happen. I love Rust, it's my favorite language. But there are times I have to use C since it is common (like when other groups may be consuming my code and they might not know Rust).

If only C was invented with the experience of using C...
>>
>>106624292
If some pattern of go-to use is sound and useful, it probably recurs often enough that you can abstract it into a control structure. Otherwise it's probably spaghetti. There never was a real contradiction between the basic premise of structured programming and the complaints about the limitations of being restricted to only a small set of control structures. Structured programming can be implemented in a limiting way but it doesn't have to be.
>>
nothing, C is already perfect
>>
>>106621684
Don't create C at all and let good languages like PL/I, Pascal, Algol, BASIC, and Fortran remain popular instead of getting killed off and replaced by C.
>>
>>106624292
Pascal has goto and it's more powerful than C's goto because it can jump out of functions (Lisp, PL/I, and Algol have that feature too).
>>
>>106626213
Someone else would create C and it would take over. Because it's just better
>>
File: 1758220253565.png (111 KB, 1634x2224)
111 KB
111 KB PNG
henlo
>>
>>106626505
C is not better. C took over because AT&T gave Unix away to universities because they weren't allowed to sell it due to anti-trust laws, so all the operating systems like TOPS-20, ITS, OS/360, UCSD-Pascal, etc. were replaced by Unix systems. C was just the "long march through the institutions" applied to operating systems. College graduates learned C instead of Algol, Pascal, or PL/I because they used Unix, so they brought C to their jobs.
>>
>>106626543
C is better than Algol, Pascal, and PL/I.
And you are rewriting history. Lots of universities didn't use unix. It spread because people liked it and wanted to use it instead of the far inferior "TOPS-20, ITS, OS/360, UCSD-Pascal"
The extreme example is MIT, they came up with so much garbage but eventually even rms had to concede and base GNU on unix because the MIT garbage was not viable.
Same with C, people wanted to use it. Unix came with a Fortran compiler since v7. People preferred to use C.
>>
File: hehe.png (95 KB, 301x356)
95 KB
95 KB PNG
>>106621684
scrap the idea and build rust
>>
File: xp3o04zcich71.png (16 KB, 640x360)
16 KB
16 KB PNG
>>106624130
MUH HEADLINES !!!
> one unit test out of 999 failing probably because of .clone() spam
>>
>>106621684
>no headers, or at least heavily limit the scope of them. Zero code allowed.
>smarter including, don't crap out with multiple/circular references
the way multiple files were linked together in a single project was always a hack, even with the limitations of the time it could've been done better
>>
>>106621684
Fuck C and fuck UNIX. The future is ours, chuds.
>>
>>106621684
By making it basically javascript but with strong types.

(at least twelve people will have a heart attack or meltdown reading this)
>>
no headers

>but muh 1972 hardwa-
no headers
>>
>>106627056
His complaint about C is that it's too low level. That's kind of irrelevant for this conversation. High level languages exist and are hugely popular. There will always be a need for a low level language more portable than raw assembly
>>
>>106627442
How are you supposed to use third-party libraries without headers?
>>
>>106627469
truly a mystery since c is the only language to ever support third-party libraries
>>
>>106627490
Other languages do it with their versions of header files.
Rust can't do it at all, you literally can't ship a closed source Rust library, I suppose some hippies think this is a feature?
>>
>>106621684
> Make all optimizations opt-in
Yes, lets make the language as slow as treacle. Making "volatile" semantics the default would be profoundly stupid.
> Clearer syntax
Using pointer syntax similar to D would be good. The intermixing of type and variable name is indeed a bad thing. The rest of the C syntax is fine, I personally despise how languages like Rust look.
> Modules instead of headers
Modules fucking suck. I have never come across am module system I did not hate. Headers just work.
>>
>>106621684
Namespaces
Methods
Destructors
Explicit copying
Explicit casting
Move by default
Length prefixed strings
(args) => ret syntax for function pointers
Type deduction
Procedural macros
>>
>>106628029
>(args) => ret syntax for function pointers
The only actually good suggestion in the entire thread
>>
>>106627569
>you literally can't ship a closed source Rust library, I suppose some hippies think this is a feature?
You can? extern exists
>>
>>106627569
what does a java header file look like?
>>
>>106622402
>C has a parser with lookahead and lookbehind
That doesn't make complex function pointers any easier to read for humans. Quite the opposite.
>>
>>106628201
What is an extern declaration if not a line from a C header, rewritten in Rust? It has the same function (define an ABI) and the same format (function signature). In C you don't need to write extern declarations because you can just include the header files. If extern is your solution then congratulations, you have reinvented the same mechanism.
>>
>>106628201
Oh and the reason I said "you can't ship a closed source Rust library" despite the presence of extern is because extern is just C FFI. Yes, you can use it with Rust. But if your code involves Rust libraries pretending to be C and talking to each other over C FFI then you have programmed yourself into a corner and should reevaluate your life choices.
>>
>>106621684
>You got hit by truck-kun and got isekai'd to 1972 in the body of Dennis Ritchie. What changes do you make to C before it becomes the default for all systems programming?

C was already old technology by 1972; if i go back to 1972 then I bring the improvements in compilation and garbage collection from 2025 and bring them a fast compiled Lisp they can use to do all kind of programming including systems programming.

OR, if that isn't possible, i tell them to use p-code Pascal, which was just being invented, and I'll tell them that (bytecode compilation) is the way of the future.
>>
>>106626543
>C is not better. C took over because AT&T gave Unix away to universities because they weren't allowed to sell it due to anti-trust laws, so all the operating systems like TOPS-20, ITS, OS/360, UCSD-Pascal, etc. were replaced by Unix systems. C was just the "long march through the institutions" applied to operating systems. College graduates learned C instead of Algol, Pascal, or PL/I because they used Unix, so they brought C to their jobs.

True, based, redpilled.

>>106626771
>C is better than Algol, Pascal,

No, it isn't.
>>
>>106621684
Make integer sizes explicit instead of architecture dependent.
Make UTF-8 the default for all strings (although it didn't exist yet back then).
Implement primitive classes (no inheritance), perhaps even replacing structs.
>>
>>106621684
I would remove:
function pointers,
structures,
arrays,
the standard library
Let me explain why. I'm lazier.
>>
>>106621684
Volatile isn't necessarily cached, though
The keyword just tells the compiler to not optimize it out.
>>
>>106628478
>What is an extern declaration if not a line from a C header, rewritten in Rust?
Yes it's the same thing.
You claimed that Rust can't ship closed source libraries because it lacks headers. But it has extern, it's same shit minus the awkward text preprocessing macros.

>>106628512
>But if your code involves Rust libraries pretending to be C and talking to each other over C FFI then you have programmed yourself into a corner and should reevaluate your life choices.
There is no such thing as "C FFI". C ABI is not standardized, it just means do whatever is the default calling convention chosen by the OS authors and some rules about struct layouts. If a code wants to run a function from some dynamic library, it will call it differently on Windows and Linux for example.
C is barebones so its ABI doesn't need to do anything beyond that. And that's why it is the facto standard for FFI. That doesn't mean there is any C code involved, it just means that a Rust code that wants to talk with C++ code will do so using bare pointers, integers and structures that are constructed in specific way, instead of talking about things like lifetimes or inheritance that only one language has semantics for.
>>
>>106621684
nuke libc, add slices to the language, make overflows and underflows panic, add explicit saturating and wrapping arithmetic, that's it.
>>
>>106629064
[spoiler]or just use zig instead[/spoiler]
>>
>>106621684
C has already been rewritten with Zig, Odin, C3, Hare. They all use manual memory management but have protected arrays and pointers and much better error handling and memory allocation than C. All these language were strongly inspired by Jai which still has not been released yet.

Rust requires too much mental effort to fight the borrow checker and is not worth it considering all the above languages make memory management in programs much easier to trace than C because the syntax makes all memory resources top level.
>>
>>106629364
>>106629483
>Zig, Odin
Ew
>C3
Not familiar with it, I'll check it out.
>Hare
I forgot about this one. It's rather nice, but I never took the time to use it since it wasn't mature.

>Rust requires too much mental effort to fight the borrow checker
Filtered. It takes time to learn to think in terms of ownership, but it's worth it.
>>

C++23 style:

for (auto const [index, num] : std::views::enumerate(numbers))
{
++num; // the type is int&
std::cout << numbers[index] << ' ';
}

C style

INT count = sizeof(arr) / sizeof(arr[0])
for (int i = 0; i < count; i++) {
arr[i] += 1;
}
>>
>>106629483
>All these language were strongly inspired by Jai which still has not been released yet.
Zig and C3 predate Jai.
>>
>>106629532
Hare is dead on arrival because it doesn't support Windows or Mac.
>>
>>106621684
Sure, I'll make some changes to C. Like a memory-safe compiler and slightly more OOP support.
More importantly tho, if you put me into Dennis Ritchie's body in 1972, then within the next decade or so, Dennis Ritchie would "invent" Python, Java, and maybe even Lua. Before the internet becomes common, he'd also provide HTML, PHP, and JS.
Not with all libs or anything - let others flesh them out later. Still, Dennis Ritchie would be the original creator of all these languages.
>>
File: minky momo.jpg (16 KB, 640x480)
16 KB
16 KB JPG
>>106622092
Depends on how far you want to go back into Truck-kun lore
>>
>>106629979
Skip Java. Go directly to wasm and then a bunch of languages that compile to it.
>>
>>106629964
Hare is designed to be a 'hundred year systems language'. They purposely are not supporting it on common platforms until the language is finalized and guaranteed to not change or ever change.
>>
>>106630041
I guarantee it will not support those platforms in those 100 years. Bookmark my post.
>>
>>106630074
saved
>>
>>106629979
>Dennis Ritchie would "invent" Python, Java, and maybe even Lua.
Lisp, Smalltalk, and Simula 67 already did most of the things those languages did, and they're older than C. He made C because he was not capable of making a compiler for a better language. If you had his brain, you wouldn't be able to "invent" those languages either.
>>
>>106629979
>if you put me into Dennis Ritchie's body in 1972, then within the next decade or so, Dennis Ritchie would "invent" Python, Java, and maybe even Lua.
Dennis created Limbo which is a Java like language that ran on a VM and was meant to be used on the Inferno operating system which was an OS that ran on a VM that Dennis co-invented.
>>
I would make C a Lisp.

>>106626771
>C is better than Algol, Pascal, and PL/I.

How is C better than those languages?
>>
>>106628631
> Make UTF-8 the default
Character encoding has nothing whatsoever to do with the language.
>>
>>106621684
Anyone who says "make rust" or "make Odin" is not thinking rationally. Back then, portability meant more than just "cross compile to windows/linux". C had to provide guarantees that will let a sufficiently adept programmer make correct programs for both 4bit byte machines and 16bit byte machines. If C decided not to care and only support 1 specific processor, C wouldn't have grown. Meanwhile Odin/Rust struggles to cross compile bug free out of the box

That said. Here's my list. I'm not an expert in old computers but I think all this is reasonable
- arrays don't implicitly decay to pointers. Arrays will simply be a size_t followed by the array. Want the raw pointer? &arr[0]
- in fact no implicit conversions at all
- module scope everything. No more #include
- no forward declaring functions
- function overloading
- string view added to stdlib

Renaming fucky functions like strtol is tempting but I can understand losing the battle there with people who were only coding in punch cards just 10 years earlier
>>
>>106630857
it kinda does doe nigguh
>>
>>106631119
>- arrays don't implicitly decay to pointers. Arrays will simply be a size_t followed by the array.
you already have structs
>- in fact no implicit conversions at all
that'll impact performance
>No more #include
that wouldn't be C anymore
>- function overloading
no use case
>- string view added to stdlib
meh
I'd rather have C not have a standard library
>>
make
if (a == 1 && b == 2)
work as expected
add multiple assignement
And remove all the shit OP added because it would ruin the langauge.
>>
>>106624167
A major uplift in bugs. You're features lead to poor code.
>>
>>106627056
C was both easier to implement and gave you more power both low and high level than pascal, for the small price of having to "manually" manage memory (if you don't want to use a garbage collector, bound checker, linter etc)
>>
>>106621684
Make it closed source and sell it for millions
>>
>>106631790
>make
>if (a == 1 && b == 2)
>work as expected
What behaviour do you expect from this?
>>
>>106621684
pascal strings
avoid array decaying to pointers
typesafe first class tagged unions
>>
>>106621863
>>Add block expressions and a defer keyword, make return keyword optional at end of a block
>One of the most obnoxious misfeatures of Rust
Please explain more, I am working on a programming language and are trying to figure out how this should be done, any additional perspectives, thoughts, etc., would be very welcome.
>>
>>106632287
Not him, but having block expressions allows the user to write code with excessively nested expressions (akin to function calls whose argument list contains a function call whose argument list, etc.). The lack thereof forces users to "space out" their expressions across several statements (akin to UFCS in Rust).
>>
>>106632774
Terrible post, disregarded.

Does anyone have a better answer?
>>
Just make it into Rust without references, lifetimes, generics and traits. Here you go, perfect, minimal sys lang.

>>106632809
Why ask if you don't want to hear the answer?
>>
>>106632989
Hello troll.
>>
>>106621684
can you be more specific? syntax? features? behavior? std library?
>>
Chris Lattner the guy who made the LLVM compiler and Swift is now making Mojo which is a fast compiled language that uses mostly compatible Python syntax and is meant to replace both Python and C++ in AI programming. The backend is meant to be optimized to run on GPUs and distributed hardware.
https://www.youtube.com/watch?v=liR2Pn5Zp9g
>>
>>106634118
buy an ad
>>
>>106633639
can you be more stupid?

try reading the responses in this thread and learn something instead of spewing your ignorance
>>
>int should default to unsigned, not signed
>in fact, everything should be unsigned unless explicitly declared signed
>the most commonly used data-type is inherently not safe from UB/defers overflow to compiler, not part of the C standard
>unsigned overflow fully defined in C standard/intrinsically no UB

also, i used to be annoyed that
char a;
char b;
sizeof(a * b); // == 4

until I realized that this is because of ASM instructions/bit width of the CPU (so it's also not "wasted" calculations).
>>
>>106634535
>>int should default to unsigned, not signed
https://blog.robertelder.org/signed-or-unsigned/
>>
>>106634118
who asked
The fact that they were super cagey about access makes mojo dead on release. Nobody wants to build their shit around a closed-source system that has weird exclusivity BS. All marketing and no show, and does little more than the long-established Cython.
>>
>>106621684

anon gets run over iron knight respawn into year 2856
>>
>>106634336
calm down, it was your best friend that fucked your wife, not me.

look at the thtead. responses are all over the place. op question was too broad
>>
that's timeslip, not isekai
>>
>>106631370
> you already have structs
so? does C have to be verbose? why I gotta make a struct for every array type
> that'll impact performance
??? why would explicit conversions be less efficient than implicit conversions?
> that wouldn't be C anymore
correct. I don't want shit polluting global namespace
> no use case
my use case is me shoving different sized feet up your ass
> I'd rather have C not have a standard library
I don't think C gets popular without a standard library. C's main attraction early on was portability. Making people rewrite file reading for every platform would make it less appealing and won't grow as fast
If C's going to have a stdlib no matter what, might as well make null terminated strings work together with string views at the same time
>>
>>106623364
>You are describing Pascal, it had all that in the late 60s.
based
>>
>>106626528
>henlo
fuck off gopher
>>
>>106630202
>How is C better than those languages?

It is not.
>>
>>106631119
>Back then, portability meant more than just "cross compile to windows/linux"

Yeah? In 1972 portability meant "cross compile Windows/Linux"? Tell me where would you get "Windows" or "Linux" in 1972, you genius.

you are reasonable with your list, though.
>>
>>106634118
>Mojo which is a fast compiled language that uses mostly compatible Python syntax and is meant to replace both Python and C++ in AI programming

who cares about that meme language which btw will fail miserably. Because the people who know how to program with manual memory management already know C and C++ and will definitely NOT want to write with python syntax or anything that resembles python.
>>
>>106621684
- Remove K&R function declarations, do ANSI immediately.
- Never make variadic functions have a mandatory argument (this solves the one usecase K&R function declarations had, FFI.)
- Don't make aliasing fuckups in the language definition (it's impossible to write a memory allocator in conformant C.)
- Make the idea of undefined behavior match its original intended purpose (leaving it to do whatever the machine does naturally; to roughly quote the ANSI standard, "what is natural for the execution environment.")
- Support __VA_OPT__ right away, though perhaps in a more elegant way.
- Support typeless storage with relaxed aliasing rules (akin to what is currently being discussed for C2y.)
- Support C99-like mixing of declarations and code.
- Support __builtin_unreachable.
- Support namespaces in some form. Having enum values leak into the global namespace is horrible.
- Don't default to char*, support void* immediately.
That's off the top of my head. Those would make for a very, very comfy systems language.
>>
>>106621684
About your suggestions:
>Make all optimizations opt-in instead of some opt-out e.g. replace 'volatile' with something like 'cached' to be consistent with keywords like 'restrict'
That sounds horrible, you'd have it almost everywhere since use of volatile is quite rare.
>Clearer syntax: remove if line statements
if(a) return; and the like seems like clear syntax to me; mandating a block there would make it look strained and unnatural. Now, that might be because I'm used to this, but I don't see the downside to what we have right now. C's syntax is fairly flexible, and I see that as a positive.
>better pointer and array declaration
Fair point.
>maybe syntax closer to JS/Go/Rust with let and fn/func
ew
>Modules instead of headers
I don't think that's realistic for that time. Most compilers were built to work with minimal system memory. It'd be a nice change for today however.
>Make stdint.h the default with i8, i16, u16, etc
I believe it's fine for int to be treated as (typically) the machine word, and to reserve the typedefs for when you need a particular width for a particular reason. Much of the time you don't care if your ints are 4 or 8 bytes, so making it default to use the fixed-width integer typedefs adds mental overhead when reading code. Also, not all machines support all those types, but that's a much weaker point.
>Add block expressions
Not sure why but sure I guess?
>and a defer keyword
usecase?
>make return keyword optional at end of a block
That's complete cancer
>allow removing the rvalue from typedef to make symbol types that can be used instead of void pointers in public facing APIs
You can't do that, the compiler needs to know the precise type. We use void* as its width and alignment are known.
>Remove null terminated strings from stdc lib
Fair.
>>
>>106623461
>You have to add "restrict" to every pointer declaration, what's the problem?
You don't, you only add restrict when declaring a function with multiple pointer arguments of the same type that never alias. That's quite the minority of pointer declarations.
>The point is to be consistent about optimizations that the writer may not be thinking about.
Currently what's consistent is making the thing you use most often the default behavior, and reserving a keyword for the thing you use less often. You want less noise in code.
>>
I tried to find a small C compiler to hax the syntax but all of them seems like programmed by morons or newbie programmers.
For example:
https://git.simple-cc.org/scc/file/src/cmd/scc-cc/cc2/parser.c.html#l12
>#define STACKSIZ 50
Da fuck is a STACKSIZ?
>>
>>106629064
>make overflows and underflows panic
you have no clue how stupid you sound
yeah, let's litter the binary with panic code, fantastic idea.
treating signed integer overflow as UB is a strictly positive thing in the vast majority of situations. what's unfortunate is that there isn't a more fine-grained way to control that than -fwrapv for the minority of cases where you care about it. stdckdint.h is quite nice, sucks that it took the committee this long.
>>
>>106639847
>sucks that it took the committee this long.
52 years dude, maybe for 2080 we can have some add with carry functionality.
>>
>>106622092
It is from the third season of Bungou Stray Dogs; the last episode if I'm not mistaken.
>>
>>106639847
>treating signed integer overflow as UB is a strictly positive thing in the vast majority of situations.
can you please explain why treating overflows as UB is in any way a positive thing? Im honestly curious, not saying youre wrong. But every software exploit seems to use buffer overflows as a entrance vector. There has to be some kind of error handling mechanism that is better than UB
>>
>>106634656
>The fact that they were super cagey about access makes mojo dead on release. Nobody wants to build their shit around a closed-source system that has weird exclusivity BS.
I really dont know that much about Mojo, but just looking at wikipedia I see the language is under the Apache license. So the fact that Chris's company is making their own closed source compiler implementation is not going to prevent open source compilers from being made

>>106637782
>Because the people who know how to program with manual memory management already know C and C++ and will definitely NOT want to write with python syntax or anything that resembles python.
The main userbase that Mojo is directed at are AI programmers which is now a huge market. And people who program AI are not tied to C/C++ and I think will gladly take a Rust-like language with Python syntax
>>
>>106621684
Find a way of creating and importing modules and build projects in a way that doesn't make people want to kill themselves
>>
>>106629532
>>Zig, Odin
>Ew
what's wrong with them?
>>
>>106621684
syntax...
>function pointers are ugly
>* should attach to the type and not the identifier
>ifs and loops without braces need to go
>declaring everything at the top is retarded

types...
>char and byte should be different. not just because is dumb and confusing to newbies, but also because signed/unsigned behave differently just for char.
>I like what stdint.h is trying to do, but holy fuck is it ugly. I don't have any suggestions, so keep it as is i guess
>implicit conversions need to go. implicit anything needs to go. I thought we learned that with fortran. In the 50s.

std lib...
oh fuck where to start
>anything that is a "for conveniece" duplication of other shit needs to go. if the programmer wants it, he will write it. e.g. printf(...) vs fprintf(stdout, ...). if you are combining other functions for some performance increase, be my guest. also because the interfaces are different- see gets vs fgets
>anything that prints to a stream should be f(stream, ...), not f(..., stream)
>separate the functions that do multiple things. freopen(NULL, mode, stream) should be changemode(stream, mode). there are quite a few occurences of this problem.
>binary stream and text stream should be separate types, or seek/tell getpos/setpos should be unified.
>use an enum for the buffer modes in setvbuf. get rid of setbuf.
>put shit in the right place. sprintf belongs in stringer
>sit down with someone that understands floating point systems and add everything that is missing to float.h. c++ did this piece right.

my food is here. maybe I will continue later
>>
>>106640549
the all-father will not be mocked, you heathen

WOTAN!
>>
>>106640561
and what's wrong with the language designs?
>>
>>106640572
they started out trying to fix C and somehow made a worse rust or C++
>>
>>106640580
looks like i've hit a dead-end in your knowledge-base unless you care to demonstrate otherwise
>>
>>106640588
<fn> kill::yourself(<T> faggot)
>>
void* should be two different types, byte* and any*
byte* has sizeof((byte*)NULL) == 1, and basically behaves like a char* but with the implicit casting of void*
any* has no size and cannot have pointer arithmetic, deref, etc. done with it, but has implicit casting

byte* would be used in memcpy and functions that just work with any abstract data
any* is for type erasure, i.e. opaque pointers for user callbacks, etc.
>>
>>106640486
buffer overflows are a wholly different concept unrelated to signed integer overflows (which is how I read that post). having the compiler treat it as undefined behavior (and thus assume it does not happen) is useful, as it opens up room for certain optimizations: https://gcc.gnu.org/legacy-ml/gcc/2007-01/msg00885.html
>gcc converts (10000 * branch_threshold[i] / 1000) into (10 * branch_threshold[i]). This minor ptimization is only possible because signed overflow is undefined. If branch_threshold[i] had the value (INT_MAX / 10 - 1), say, the optimization will cause the expression to have a different result (assuming standards twos-complement arithmetic wrapping).
>In expmed.c we find several times (size - 1 < BITS_PER_WORD). gcc converts this to (size <= BITS_PER_WORD). This optimization is only possible because signed overflow is undefined. If size has the value INT_MIN, the optimization will cause the expression to have a different result.

on top of that, not all machines use two's complement (though most do nowadays). codifying, say, wrapping on signed overflow (or any other particular behavior, really) into the standard would make for terribly inefficient code for any conformant C implementation on machines that do not do that natively.
the only real practical issue with signed overflow being UB is compilers taking the liberty to silently remove naive overflow checks (there are conformant ways of checking for overflow, if ugly).
>>
>>106640780
c23 added overflow detection macros
>>
>>106640717
sounds like a fairly useless feature
>byte* has sizeof((byte*)NULL) == 1
what? you want a pointer type to be one byte wide?
>>
>>106640814
typo, sizeof(*(byte*)NULL) == 1
>useless
it's for QoL and API clarity



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.