>>101231223
yes, although c99 is all I need actually useful features being added to the language instead of the absolute clusterfuck that c++ is doing is a big win
come @ me brainlets

>>101231223
Should have printed x using %b. Also C did have static assert, they are adding a version without the 2nd argument and making it a keyword instead of a macro.

Classes next. Templates right after that

>>101231223
This color scheme gave me aids

[[]] syntax is a mistake and the whole standard committee deserves to be beheaded for including it.

Does auto work in function parameters? If not I don't see the purpose. Also wth is

1'000'000

, looks like a weird type inconsistency pulled from the black book of javascript. What's constexpr?

Other than those things it's alright ig. It will be nice to be able to use bools without including stdbool.h. I'm sure [[depricated]] will be useful for larger projects with multiple contributers.

>>101231664
[[You]]

>>101231664
t. Virgin who has never touched a [[]]

>>101231223
>deprecated
A word that aptly describes the entire C language.

>>101231365
That would brake stream isolation

>>101231836
>Also wth is 1'000'000
An extremely helpful feature taken from C++17 that allows you to use a single quote to write long numeric constants,
Its like how people use commas when writing big numbers 1,000,000 is a lot easier to read and less bugprone than 1000000.
They couldn't use commas for obvious language reasons, so they used single quotes.

>What's constexpr?
The single best feature of C++

>>101231836
>Does auto work in function parameters?
No, only for locals and only for 1 variable per declaration, do more limited compared to C++.
>If not I don't see the purpose.
I think the main use case is within macros for temporaries. Shorter than doing the same with typeof_unqual.

>>101232065
>1'000'000
is a joke. other languages have had this forever: 1_000_000 and it would have been compatible with old pp-number syntax too, but no, committee had to fuck up all existing syntax highlighters.

>>101231664
why is it a mistake?
t. only starting to learn C

>>101232525
works in vim, couldn't care less about meme syntax highlighters

int x = 1'000'000'000;

>>101232648
Because C++ only has tuple unpacking and it uses []:

const auto [x, y, z] = func();

With [[]] this cannot work with nested tuples:

const auto [[x, y], z] = func(); // no chance

I wish this was added to C as well, but it should work for structs and should work outside of declarations:

struct point { int x, z, y; };
struct point func();
...
int x, y, z;
...
[x, y, z] = func();

>__has_include
Is that really in the new revision? Horrible shit.

>>101231664
You only realize now that the C standards committee is comprised of literal idiots?

>>101232824
Just do the same like C++ when it parses << on templates.

[[deprecated("use zig instead)]]

>>101232836
It was available with GCC before. There is also standard __has_c_attribute and GCC/Clang-specific __has_attribute and __has_builtin. This allows feature detection at compile level, no need to ./configure most of cases. Good stuff.
>>101232847
Will work for most cases, but C standard prefers simpler constructs. They don't even allow implicit struct creation with {} C++ style:

struct point { int x, y; };
struct point func()
{
    return { 1, 2 }; // works in C++, not in C
    return (struct point) { 1, 2 }; // works in C, not in C++
}

>>101231223

#if __has_include (<stdio.h>
  #include <stdio.h>
#endif

What is the fucking point?
The code is not gonna compile without stdio anyway.

>>101233016
It is very common for Unix variants to has identical functionality, but in different headers. This allows conditionally including all of them. Like <linux/futex.h> vs <sys/futex.h>

>>101232899
>Will work for most cases, but C standard prefers simpler constructs. They don't even allow implicit struct creation with {} C++ style:
The C++ way is actually more convenient, as much as I hate C++. The C (){} syntax is pretty complex too.

>>101233016
To create more fragile shitware, something C specializes in.

>>101231631
Never. Not having OOP crap is a big reason I prefer C to C++.

>>101231223
Under what circumstances would I be pasting the contents of stdio.h into my translation unit but it doesn't actually matter if it's on my system because I didn't actually use any of it's forward declared functions?

>>101233086
That sounds like something that should be handled by your build system and not the language preprocessor.

File: 1719119556712541.png (169 B, 250x250)

169 B PNG

>>101231223
>int g(int x){return x + 1;}
what's the point?

File: file.png (129 KB, 680x489)

129 KB PNG

>>101231223
>int main()
where's the return value?

File: discipline.png (918 KB, 1100x1400)

918 KB PNG

Don't care, still not moving on past C89 in -pedantic -Werror mode, I even start new unnamed nested blocks so I can declare new variables halfway through a function.

>>101233718
I am of an opinion that the build system is the worst place to handle this. They don't really help - you just end up checking for HAVE_SYS_FUTEX instead of __has_include(<sys/futex.h>), so there is no difference.
Plus there are many build systems for C and I don't want my code to depend on them.

>>101233763
You would rather depend on brand new functionality that wont be added to C preprocessor implementations for a very long time?

>>101233775
>You would rather depend on brand new functionality that wont be added to C preprocessor implementations for a very long time?
Supported since GCC 10 and Clang 10. I don't care about older compilers.

>>101231223
I rather want #embed even if the one we got from the committee is a bit overcooked. It will let me reduce the mess in my Makefiles and that's a good thing.
I would really REALLY like the defer that is being mooted for the version after this one just coming. It gets me the key benefit of RAII without the frightful mess of the rest of C++ (it's a bit like the same-named feature in Zig).
I'll be unable to adopt any of this for a long while. That particular codebase has to build with GCC, Clang AND also MSVC; damn customers!

>>101231223
>we'll live to see C turning into a better zig before zig being finished

>>101231223
I hate the auto keyword. Leads to less readability and dependence on an IDE to view its type.

>>101232857

    [[deprecated("start hrt and rewrite everything in rust")]]

>C
>still struggling to gain basic features
Reminder that the C committee murdered C. They don't care about important things, only garbage like _Generic or a castrated standard thread library.

Not really, there's no point writing new stuff in languages with header files and all relevant software written in C89/99 still works fine so this evolution doesn't make much sense to me.

>>101233868
C doesn't have atrocious types like C++ that need to be hidden behind type inference to add any semblance of readability.
Honestly I think the intended usecase and the only place you'd really see them are inside macros.

>>101233885
C is supposed to be simple, stapling on modern features with the few syntax symbols left over that wont clog up the preprocessor is not real C.

>>101231223
>[[deprecated]]
Whats wrong with a macro?

>>101233988
the prevailing sentiment by nu-C programmers is that macros are evil

>>101233988
And what would be behind a macro?
Here is a macro for you (standard compliant):

#define deprecated [[__deprecated__]]
...
deprecated void f() { }

>>101233749
It's just cargoculting shit the c89 tards added I think to copy c++ or some popular c compiler but I could be wrong

>>101234037
it would replace f with gibberish? I'm sorry I don't understand the point of deprecated

>>101231223
so they conditionally included stdio, then unconditionally used a function from stdio? Am I reading this right?

>>101234070
It is just an attempt to standardize existing extensions such as __declspec(deprecated) and __attribute__((__deprecated__))

>>101231223
>typeof(x) y
weird...

>>101233749
pretty sure it returns 0 by default mang. But yes, this is pajeet-ware code for sure

>>101234070
It's designed to emit a compiler warning, which under normal circumstances would NOT be fatal.
It's for libraries that want to remove something in a future version and give users time to change, or something they even aren't going to remove because of total compatibility, but still annoy the crap out of their users to change.

>>101234097
That particular GCC extension has been with us for like 30 years...

>>101233847
I personally don't give a crap about MSCV, but even gcc and clang haven't been too quick to add support.
I think the only real case I'd use for it currently is including SPIR-V shaders directly into the build, which would definitely be nice.

>a bit overcooked
True, but it's better they went that way instead of having being ultra-basic and only supporting unsigned char arrays.
Surely people want to

#embed </dev/random> limit(256)

What so hard about #embed? I didn't read the spec.

>>101234237
>>101234207
embedding binary data into C programs is piss easy though, xxd has a mode that will emit a C unsigned char array you can #include in your source code.

File: 7499_1-600x1096.jpg (118 KB, 600x1096)

118 KB JPG

>>101234113
>>101234096
I still don't understand

>>101234237
It is stupid as fuck

int shenanigans(void)
{
    return
#embed "single-byte-file"
;
}

According to the standard, this is supposed to work.

>>101234259

$ xxd
bash: xxd: command not found

>>101234262
I don't get it either, just put a #warning.

>>101234259
The point is that parsing giant C arrays like that is slow and memory intensive as fuck, especially when you're getting into the range of tens or hundreds of megabytes. You'd even OOM shit compilers like MSVC fairly easily that way.
It took the original proposal author a while to convince the committee and even the compiler authors that.

It would be much better to use the linker directly, but it's SUPER unportable.

>>101234297
#warning always generates a warning, [[deprecated]] generates it upon use of deprecated functionality.

>>101234313
If the function is there, you used it. Don't like it then remove it.

>>101231664
What would be an alternative? Just []? At least it's not as retard as the preprocessor syntax.

>>101234343
>If the function is there, you used it.
Declarations or definitions do not count as "uses". You have to call it or take its address. It is helpful for library authors to warn users about functionality that will be removed in the future.
>>101234356
Maybe @deprecated?

>>101232857
>>101233884
kek

>>101234356
they already have reserved namespace, why not just make it it's own keyword?

void _Deprecated muh_function();

>>101234368
>Maybe @deprecated?
It's a pointless discussion. C++ did it first, the the C standards committee gives a little bit of a shit about header-compatibility, so they just used the C++ syntax.
Blame them.

>>101234310
>SUPER unportable.
But object files are basically standardized on POSIX and the same concept exists on Windows.

>>101234368
>Declarations or definitions do not count as "uses".
They literally are. Again, if you don't like it then delete it.

>>101234277
What, is it inferring the type or what
LMAO

>deprecated and nodiscard but no attribute cleanup
c23 was a mistake

>>101232824
This is an extremely retarded way to unpack a tuple. Why the fuck they didn't use just ()?

>>101234386
#emded is much better. Using the linker requires a lot of extra build system fuckery, but #embed will slot in quite nicely with the same way header dependencies work and should work correctly with minimal changes. I hope they'll be output as part of gcc -M.

>>101234383
Support ofr C++ style attributes can be queried through __has_cpp_attribute and __has_c_attribute. They are also namespaced, so compilers can puts their extensions there, like [[gcc::likely]]
>>101234409
Because in C "," (comma) is an operator and "(x, y, z)" is already a valid expression that evaluates to "z".

>>101234402
#embed is supposed to expand into a list of integer constant expressions
e.g.

char my_bin_data[] = {
#embed "whatever.bin" suffix(,)
    0x00 // Null terminating the string without the file itself needing to do it
};

// e.g. normal case
char my_bin_data[] = {
    0x01, 0x02, 0x03, 0x04 ,
    0x00
};

// say the file is empty
char my_bin_data[] = {
    0x00
}

The operations are
- limit (how many bytes to read)
- if_empty (replace with this expression if the file is empty)
- prefix (place before if non-empty)
- suffix (place after if non-empty)

>>101231631
SIRS

>>101234567
Suffix is dumb. #embed should have just expanded to the list with trailing command. C supports them since C11? C99?

char my_bin_data[] = {
#embed "whatever.bin"
    0x00
};

>>101234610
It could be used for more than that. Any expression could go there, not just a comma.

>>101234632
Yeah, can't wait for compilers to support #embed so I could store all my function return value in single byte files.

>>101234262
Deprecation is a hallmark of shitty devs who fled the sinking ship of java and javascript projects where API stability is unheard of. It's considered good practice in those communities to preemptively deprecate every function you write. This change gives this mindset first-class citizenship in the C compiler, so that devs used to such practices have a more comfortable and welcoming experience.

>>101234567
>what if I came up with an inelegant idea
>and add so many bells and whistles until it fits all use cases I could come up with

>>101234683
You're a retard.

>>101234750
>>and add so many bells and whistles until it fits all use cases I could come up with
Right, that's kind of how languages and standard libraries work. They typically want things to be very general purpose.

File: output.png (79 KB, 990x801)

79 KB PNG

Skimming over the spec, man some silly stuff gets in there sometimes.

>>101234920
The CHAR_BIT!=8 is dumber than the uwu thing.

>>101231223
>constexpr
it is over, C is officially a joke.

Anyway, vanilla c++ stomps.

>>101231223
Niggerlicious. We need to go back.

>>101234977
There was this project (it was FTL for SSD) that had to use lots of constants that were evaluated base on other constants. Some of resulting expressions after macro expansion were so long they crashes compilers. True story.

>>101234977
The C version is MUCH more limited in scope than the C++ version.
It's basically just a static const variable, but it gets to be an ICE according to the language's rules; #define but actually with types.

#include <stdio.h>

struct thing {
    unsigned char a;
};

constexpr struct thing t = { .a = 10 };

int main(int argc, char *argv[])
{
    if (argc != 2)
        return 1;

    unsigned char n;
    if (sscanf(argv[1], "%hhu", &n) != 1)
        return 1;

    switch (n) {
    case t.a: // Couldn't do this before
        printf("!!!\n");
        break;
    default:
        printf("...\n");
        break;
    }

    // Fine too
    const struct thing *ptr = &t;
}

>>101234343
>use shitty library x
>update library version
>functions missing
>wat
>join their irc channel to ask about it
>get told they were deprecated version before and should read some shitty mailing list
>get kickbanned

So point of it is that it now tells you that you are using shit that is going away so you don't need to go cry about it to whoever is responsible of that library. Sure this still doesn't affect case when you update some library so randomly that you skip over lot of versions at once. But that is for dev to decide how long they warn retards.

i still use ansi c

C++ bros are winning again

template <typename E>
  requires std::is_enum_v<E>
constexpr std::string enum_to_string(E value) {
  template for (constexpr auto e : std::meta::enumerators_of(^E)) {
    if (value == [:e:]) {
      return std::string(std::meta::name_of(e));
    }
  }

  return "<unnamed>";
}