Hacker News Reader

I can’t say much for most of your wish list, but I believe C11’s thread model/atomic operations include a standard memory barrier ( http://en.cppreference.com/w/c/atomic/atomic_thread_fence ).

Honest question. You keep expecting all of these to be readily available for you in C (as part of the standard). Why don't you, instead, just a use a language/ecosystem which already offers all (or most) of these for you today? (ie. D/Go/Rust/Nim)

> "* Reference counted allocator (basically, get libtalloc and roll it in [1])"

Why and how should that be standardised exactly? Memory allocation is platform-dependent, hardware-dependent and generally case-specific. malloc() and free() are the lowest common denominators the standard can assume, anything beyond that is simply restrictive. If you need a "reference counted allocator", why not just find/implement one that simply suits your needs?

> "* Coroutine standardisation would be awesome (stack swap primitives, with boundary checks etc)...."

Again, what makes you think this can be standardised across the infinite span of platforms and compilation-targets, where C is often used?

> "* In fact I want SIMD. I don't need these complex types."

I'm not following your point. You're simply asking for a better abstraction for SIMD. Also, as I'm sure you're well aware, SIMD is not available everywhere. Wherever available, you have clear instruction-set APIs/ABIs you need to follow to make it work. What else is missing?

I don't see your point. There's tons of stuff in C11 for example that is not applicable to a vast majority of where C is used. Even in C99 basic stuff as 'floating point' or 'malloc' is not available on many hardware, that doesn't stop having a standard way of using them /when applicable/.

I know there are traps to fall into -- when I see people writing floating point code on an 8 bit AVR, I cringe, but well, 'it works'.

As far as changing language, you just answered your own question by mentioning 4 of the myriad of them that aren't ported on as many platform as C, requires runtime of unknown quality, and also requires a body of developers that... doesn't exist.

I've had a long enough time in the industry to have seen quite a few times a whole bunch of software done by someone who was following the fancy trendy language of the day, and required a complete rewrite in... C to be able to move on from it.

Heck, I've done similarly as well, done 20+ years of C++, gradually trying to scope down the subset of what I was using to then realize I just might be better of with plain C -- and magic happened -- stuff still compile/work years after they were made... And anyone/everyone can just dive in and use the codebase.

Looking at C2X list, I bet you aren't getting any of those wishes.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/PreBrno2018....

I am with you on strict boundary checking and array base types.

> weird stuff nobody needs (complex math anyone??!?!).

in my work (signal processing) I use complex math in C every day, and native language support for complex numbers is the single most important thing in my choice of C over other languages

> I want an array base type that can't be cast as a pointer

just out of curiosity? why would you like that?

I mostly agree with the spirit of your comments (apart from neglecting the importance of complex math). I would add the following:

* better stack support (e.g. a standard way know whether a VLA fits)

* closures (being able to return a pointer to a local function)

> in my work (signal processing) I use complex math in C every day, and native language support for complex numbers is the single most important thing in my choice of C over other languages

Fair enough -- but I think you are in a fairly corner market -- personally I think I used complex math /twice/ over the last 30+ years... I used SIMD extensively tho, from Altivec onward!

>> I want an array base type that can't be cast as a pointer

> just out of curiosity? why would you like that?

For bound checking. In C right now if you declare a char blob[4] and pass it as parameter to anything, it's passed down as a char * mostly -- and that function can clobber whatever it likes. An array type would propagate the size down so bound checking can be done at for the whole lifetime of the array.

> * better stack support (e.g. a standard way know whether a VLA fits)

Yes, anything involving stack requires serious dirty hacking -- even for basic things as 'what are my high/low water marks'. Basically your stack is just a problem waiting to explode in your face, especially on smaller devices.

> * closures (being able to return a pointer to a local function)

That's mostly what I meant by sub-functions -- I used them quite a bit, until I had to crossport to llvm (they refused to implement them). Apple "blocks" look pretty good, but I know there are a couple alternative implementations...

> Fair enough -- but I think you are in a fairly corner market -- personally I think I used complex math /twice/ over the last 30+ years... I used SIMD extensively tho, from Altivec onward!

One of the best ways to implement SIMD support for C would be to add native quaternion and octonion support to the language!

For addition and subtraction, that sounds like one of the most evil-assembly-hack tricks I've heard for a high (-er than assembly) level language, but how would you do ... pretty much everything but addition and subtraction?

there are a lot of operators in the C language that could be overloaded as SIMD operations when acting over quaternionic and octonionic values. This would be useful for the most common operations. For the rest, there would be functions with well-thougt names (not the current avx monstrosities), defined on #include <octonion.h>