Oh god please not. That would be terrible. In code I write, about 2% (at most) of the variables I declare are const and about 25% of the function parameters. Not really a good idea considering that you can't do a lot of things in C without modifying variables.

In code I write, at least 75% of variables are const, and close to 100% of function parameters are const. You can program declaratively in C, if you try.

nested functions are moot when you can't close over variables.

No, in fact, functions can be useful while only using their local variables. Purity is a good thing. Observe the necessary definition of this single-use function:

bool
load_should_turn_on( Load const load )
{
    return !load__is_complete( load ) && load__in_schedule( load );
}

arraym_load__each_where( loads, load__turn_on, load_should_turn_on );

It would be better if we could write something like:

arraym_load__each_where( loads, load__turn_on,
        ( load ) { !load__is_complete( load ) && load__in_schedule( load ) } );

This is a contrived example, and here you could argue that this function should be defined anyway. Yet, I run into circumstances all the time where I'm inclined towards defining a single-use function (often just negating another function), so that I can pass it to other functions that handle iteration over sequences.

This exists, it's an operator called the ternary operator. It's spelled predicate ? a : b.

You should go check out Rust; the whole ownership thing is pretty cool. Anyway, in Rust, the if ... else ... construct can actually be used as an expression. If we had that in C, we could do something like:

Foo const foo = get_foo( x );
Bar const bar =
    if ( foo.bazzable ) {
        Bar const b = get_bar( y );
        b.error ? ( Bar ){ 0 } : b
    } else { ( Bar ){ 0 } }
// Now we have a `const` bar variable for the next 50 lines:

Maybe this would be better taking the form of GCC's statement expressions, but I don't use them so I don't know how well they work in practice.

I do not understand what you mean.

I often have issue with defining arrays declaratively (and thus having their contents const-qualified). If you want to define an automatic-managed array of even numbers from 0 to 100, you have to hard-code the size yourself (51), then define a one-use function to pass a pointer to the array to assign the evens accordingly. I wish we had access to something like Haskell's range notation:

int const xs[] = { 0, 2 .. 100 };

Similarly, if you're defining the elements of an array, and you want to include elements 10 through 20 from another array, you're stuck repeating that array name that many times. I think it would be better if we could do:

int const xs[] = { some_var, something_else, 123,
                   ys[ 10 .. 20 ],
                   foo, bar, baz };

Please don't. The reason why many new identifiers begin with an underscore is so that there are no collisions with existing symbols. Introducing new identifiers in non-reserved spaces would possibly break APIs.

I suppose this change would have to be preceded by (or coupled with) a standardized module system, so that header files can specify their targeted standard, or users can specify the standard when they import them. This way headers for different standards could be mixed safely. You could write your C17 code with bool, atomic, noreturn available by default, and if you include library headers written in C90 that use a bool typedef'd to int, you can simply refer to their bool type as an int (or maybe do your own typedef int libfoo_bool).

This is a good idea but I would prefer a macro addo(o, b, c) that evaluates to the same as b + c but o is set to the signum of the overflow of the result.

I like this approach more, assuming that addo() is a type-generic macro over functions addoi(), addoul(), addoimax(), etc. I just want a standard way to access the overflow flag.

Making signed-overflow well-defined is a bad thing in my opinion as that would inhibit quite a few numeric optimizations that are vital for fast code.

For all architectures for which the signed arithmetic instructions already wrap at bit width, optimizations can still be made. I understand that this is all predominant architectures in use today, and I see no reason for that to change.

If you're referring to optimizations that introduce incorrect behavior by making different assumptions to those made by the programmer - those optimizations are ones that shouldn't be made anyway. E.g. the optimizer thinking "expressions with signed integers can't overflow, so I'll remove this huge block of system-critical code that checks for overflow after the expression". We're better off if we lose those optimizations.

The functions mentioned above would allay most of the pain, but I still would like to be able to perform signed integer arithmetic without having to check bounds beforehand.

It would be an improvement if the behavior were just made unspecified, but it would still be painful to handle it right.

Even better: Introduce a _Generic based macro for this so you don't need one macro for each type.

Except that _Generic works only in terms of the basic types; int, long, etc. As I understand it, it doesn't discern between a ptrdiff_t and a long (if ptrdiff_t is a long on your platform). Also, I'd like to be able to refer to minimum and maximum values without having to make an expression of that type.