Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C-for-all: Extending C with modern safety and productivity features

cforall.uwaterloo.ca

Post reply on HN
Print view View original

61–70 of 143 posts

Re: C-for-all: Extending C with modern safety and productivity features

#61

Post by Quequau »

karlding wrote: post #35
Quequau wrote: post #11

This has been posted here a couple of times in the distant past but for whatever reason I can only find one old post: https://news.ycombinator.com/item?id=9829133 Anyway, it seemed like an interesting project the last time I looked at it but Rust wound up getting all my attention.

Here's the discussion from 2018 [0], which has some responses from people involved with the C-for-all project. [0] https://news.ycombinator.com/item?id=16657385

Yes. That's actually the discussion I was looking for. Good find.

Re: C-for-all: Extending C with modern safety and productivity features

#62

Post by kannmig »

pcr910303 wrote: post #20

I really don’t need an extended-C with productivity features... as that’s one of the defining points of C(the language is small). Fixing the warts (like different behavior between the overflow of unsigned ints & signed inta) would have been fine. I personally want a better stdlib for C; fix the defiancies of , removing the global locales (changing function behaviors according to LC_* was a really, really bad idea[0])…

https://www.musl-libc.org/

Re: C-for-all: Extending C with modern safety and productivity features

#63

Post by lerno »

rwmj wrote: post #55

Can we talk about the proposed new features: How are tuples different from structs? You can pass around and return whole structs (not pointers) just fine in plain C. Underscores in int literals should probably be proposed to the ISO committee for C itself. A similar concept works successfully in OCaml. (Binary literals would also be useful). I've never felt that C lacked sufficient control structures, and the new one…

I wonder how they propose to solve exceptions, destructors, constructors and overloading while being more compatible with C than D. Apparently a beta was promised for "early 2019" according this: https://github.com/cforall/cforall but nothing is forthcoming.

Already announced in 2007: http://lambda-the-ultimate.org/node/2181

Re: C-for-all: Extending C with modern safety and productivity features

#64

Post by saagarjha »

kannmig wrote: post #62
pcr910303 wrote: post #20

I really don’t need an extended-C with productivity features... as that’s one of the defining points of C(the language is small). Fixing the warts (like different behavior between the overflow of unsigned ints & signed inta) would have been fine. I personally want a better stdlib for C; fix the defiancies of , removing the global locales (changing function behaviors according to LC_* was a really, really bad idea[0])…

https://www.musl-libc.org/

That doesn't fix the issues mentioned. (Whether it's an "alternative" stdlib for C is debatable; nobody ever said that glibc is "the" stdlib for C…)

Re: C-for-all: Extending C with modern safety and productivity features

#65

Post by makapuf »

kwhitefoot wrote: post #58
makapuf wrote: post #19

Earlier quoted context omitted.

Yes, some of the many features : Tuples, left to right declaration syntax, references with auto dereferencing, constructors destructors, nested routines, extended case with ranges, choose (switch with no fallthrough), overloading and polymorphism.

Quite lot of that sounds like Turbo Pascal/Delphi.

The even added with for structs member usage in a block.

Re: C-for-all: Extending C with modern safety and productivity features

#66

Post by saagarjha »

GlitchMr wrote: post #60

Wow, this is quite a trainwreck. I think it's possible to improve C while keeping compatibility with C programs, but that's not how you should do it. I think an improved C would be quite useful, but you really should be careful with what you include it, and keep the language simple. A lot of functionality feels like added because it could be added (WTF are nested routines). This way lies worse C++. In particular, I w…

Who owns the return value of new_point?

Re: C-for-all: Extending C with modern safety and productivity features

#68

Post by GlitchMr »

saagarjha wrote: post #66
GlitchMr wrote: post #60

Wow, this is quite a trainwreck. I think it's possible to improve C while keeping compatibility with C programs, but that's not how you should do it. I think an improved C would be quite useful, but you really should be careful with what you include it, and keep the language simple. A lot of functionality feels like added because it could be added (WTF are nested routines). This way lies worse C++. In particular, I w…

Who owns the return value of new_point?

The function that calls `new_point`, the value is moved. Similarly, consider the following case.

    struct Point a = new_point();
    struct Point a2 = a;
Assuming `struct Point` has a destructor, this would move `a` into `a2`, and prevent accesses to `a` after `a2` assignment, as `a` is no longer considered to be alive at this point. C++ has a wrong default of cloning instead of moving, but a new language could fix that.

Re: C-for-all: Extending C with modern safety and productivity features

#69

Post by nirui »

dvt wrote: post #7

I'm sure a lot of very smart people are working on this, and I don't want to detract from their dedication, but man this language looks like a mess. And in no small part because it wants to be backwards compatible with C (the reasoning is unconvincing -- why not just use C++?). In the age of Go and Rust, which already have a hard time finding niches, I don't really think there's any room for a language like this. And…

> In the age of Go and Rust, which already have a hard time finding niches

To make the time even harder, in that niche space, you already have decent enough languages like Nim and Zig etc.

So yeah, the market is really pretty saturated, I don't even have time and project idea to try them all, let alone bring them to work.

Re: C-for-all: Extending C with modern safety and productivity features

#70

Post by hybrids »

kannmig wrote: post #62
pcr910303 wrote: post #20

I really don’t need an extended-C with productivity features... as that’s one of the defining points of C(the language is small). Fixing the warts (like different behavior between the overflow of unsigned ints & signed inta) would have been fine. I personally want a better stdlib for C; fix the defiancies of , removing the global locales (changing function behaviors according to LC_* was a really, really bad idea[0])…

https://www.musl-libc.org/

musl is just another implementation of the true stdlib. I think what they want is an alternative to standard-conforming stdlibs that fills a similar niche - in other words, a "non-standard" standard library.
Post reply on HN