Hacker News Reader

Comment by squid_demon | Hacker News Reader

Please leave C alone. Thanks much.

Some sort of type inference would make a lot of sense to close some left-over holes from C99:

E.g. why does this work:

    struct bla_t bla = { .x=1, .y=2, .z=3 };

But when I want to assign to an existing variable a "type hint" is needed:

    bla = (struct bla_t) { .x=1, .y=2, .z=3 };

Why the (struct bla_t)? The compiler knows the type of "bla" after all.

Also this would be nice to create a zero-initialized struct value:

    const struct bla_t bla = {};

...this would basically be a C99 designated initialization without any initializers (it works as a language extension in gcc and clang, but is an error in MSVC).

Second this. These are some of the most annoying syntax warts.

Another thing - that probably has no resolution - is the struct-tag thingie. Even after all those years I'm not decided if it's worth typedefing structs to remove the struct tag. Like

    typedef struct _FooBuffer FooBuffer;
    struct _FooBuffer {
        ...
    };

    // now we can declare FooBuffer variables without struct tag:
    FooBuffer foo;

   // had we just declared struct FooBuffer { ... } (without
   the typedef), then we would have to do
   struct FooBuffer foo;

As almost everybody, for a new language I would not want to have any struct tags. Even though the argument from the Linux Kernel code style guide makes some sense to me ("don't typedef struct tags away because we want to see it's a struct"). Each struct keyword moves the following code 7 columns to the right, which is annoying in lines where there are 3 or more of them.

Thanks to the sheer number of C programs, no compiler supporting later C standards will drop support for prior standards unless it's explicitly targeting the later standard and that standard is fundamentally breaking with earlier ones. And even then, the major players won't because they still have to support every program ever written in C.

So any changes to C at this point will not break your ability to use whichever prior C standard you happen to be interested in.

Except when you come to a new company and find out they're using the new glory all over the place and insist you do too.

Well, if you join a team you join whatever they're using. Which may not even be C. If you want control, you have to lead the team in the company or run your own company. That's part of being a "company man". You forfeit control over the kinds of things you work on and many decisions about what and how they're made unless you have the right ear or the right level of authority.

And that's why the commenter wants people to not touch C - if C doesn't change then the workplace won't change too.

I mean, you can try and hold back the tide but the world changes. Take control of your section of it if you want control, but you can't stop change. Perhaps try to become as relatively unpopular as Common Lisp so that no new standards are ever made (though the community continues to extend the language environment with things like QuickLisp and Alexandria). Or as truly unpopular as JOVIAL so that there really are no more changes.

Not everyone has the means to become their own employer. I agree with you about control and I myself am in business for this reason, but suggesting that they should simply use whatever they like doesn't address the problem.

Blowing up language is not nice even for me as a businessman - now I have to place special care about who's coding what and how, something I didn't need to do up until now (in case of C).

> Blowing up language is not nice even for me as a businessman - now I have to place special care about who's coding what and how, something I didn't need to do up until now (in case of C).

This part is fair, but I've never worked (professionally) in a language that had a BDFL who controlled its extension in a deliberate fashion. It's always been design-by-committee languages. As a consequence, since I began, we've always had coding standards that limited what portions we could use for which projects (usually with options to try out novel parts of the language/standard library with extra reviews). And this is even true with C, though the restrictions weren't as severe (working in embedded, typically mandating no/limited use of malloc/free and no recursion, direct or indirect).

Or companies will leave C behind.

MSVC 2019 enters the bar with support for C89, C11 and C17.

Though they never actually dropped C99 support, they never had full C99 support to begin with. C has long been a second class citizen (compared to C++) under MS's development tools.

They had C99 support to the extent required by ISO C++ compliance.

The backtrack from "we don't need C anymore" is most likely driven by, WSL, Azure Sphere OS, Azure RTOS, and above all probably some vocal customers with enough power to make it matter.

Even the Windows kernel team dropped the COM based userspace drivers framework, replacing it for a C based one.

In any case, everything from C99 that became optional in C11 isn't planned to ever be supported.

You can always set your compiler to accept only older standards...

Yes, and please leave C++ alone too, at least for 20 years.

Reply on news.ycombinator.com