uecker

What I do not get is the "can be used as built-in" part. What exactly does this mean? You can enforce invariants by encapsulating structures behind an API. This works fine in C (even bette…

Why would this be required?

It is true, I feel pretty lonely in WG14 pushing these ideas sometimes. But it is not that we haven't made progress: When I joined there was only a vague understanding of of the memory model and…

Straw man fallacy. .

Indeed, the double consumption you can not express in C. But invariants of data structures are not a practical problem in C. Looking at the Rust code of this project though, I trust my C code a lot mo…

I think an object ownership system is something we should have in C. Otherwise, i am relatively unimpressed TBH. And readability of this is questionable: https://cs.opensource.google/…

What is described there, seems basic encapsulation to me. We do this too in C with structure types and API around it that enforces the invariants. So C is a X-safe language too? Or what am I missing?

The thing with UB in C is that it was traditionally seen also as a possible extensions point, so someone else can come in and define the behavior, e.g. POSIX does it for some. But yes, we understood t…

The things you mention are already ongoing. We eliminated 15 items in J.2 in last meeting and will remove more in the next. Not that I agree that the UB is really the that much of a problem, only very…

But Rust shows that static detection is possible if you add constraints to the language, and this is exactly what one can do it C too. Rust was inspired by a C dialect after all. The situation with U…

Not if this means horrible long compilation times. I agree it should be catched before a release. But this is a question of procedures and not of programming language.

I do not think newer languages are the solution for two reasons: First, all those new languages also have various downsides, and trade-offs, which may make them a less than ideal choice for many appli…

It is the same problem in C and more manageable. I just doubt the "dramatically". And C problems also become more manageable with better tools and more focus on safety in the language evolu…

Rust has quite a few problems which why I would not want to use it for my projects: High complexity, long compile times, not stable, not standard, supply chain issues, etc.

Rust makes a lot of things hard. Update: From your CVE "Clear warning that read ucode[] may out-of-bounds." So it seems this was catched by tooling.

I see Rust code with quite a lof of unsafe and sometimes it has bugs, sometimes triggered from preconditions broken outside of the unsafe block. So no, I think it is an oversimplification to pretend t…

Safety in C improves dramatically with good tooling and coding practice and you can slowly move to safer C without much pain. People who really do not care will also create problems with Rust.

I am impressed by Haskell, Prolog, but also ... C.

Yes, right. Thank you. (although in terms of semantic changes, I am not sure)

There are various modifications being done after the final public draft. But N3220 is very close: https://www.open-std.org/jtc1/sc22/wg14/www/projects#9899 …

https://gustedt.gitlabpages.inria.fr/modern-c/

The ISO C23 standard got published as ISO/IEC 9899:2024. Public drafts can be found here: https://www.open-std.org/jtc1/sc22/wg14/www/projects#9899 …

Of course it also works with void*.

The wording is very unfortunate, he makes valid points though.

I am skeptical about this. Optimizer can also specialize functions and programmers can do too. Excessive specialization you get with templates always look beautiful in microbenchmarks but may not be i…

Dependencies... I just leave this here: https://internals.rust-lang.org/t/type-inference-breakage-in... …

make and compilers are usually reproducible. Most Debian package are reproducible, so this is perfectly feasible.

I maintain a fairly complex computational project about 10 years now... I do not see these problems and I would not want to do this in Rust (after studying it for a while). Mostly I like me extremely…

I find the mental load in C very light and I rarely use a void pointer in C. I also like headers, they give a clean separation of implementation and interface and enable very fast compilation.