thetic

I don't even think that's a controversial opinion. Breaking convention isn't inherently bad; it has costs, some of which you described. In this case specifically, the novelty is not justified by any significant benefit.

If only there were a way to indicate the function argument isn't mutated. </s>

My spidey senses tingle whenever I see const-ness cast away because it almost always means something is wrong. Either a function is missing a qualifier on an argument, or something very unsafe is happening. Why force callers to cast away const-ness in hopes that everything will be fine when you can just write the correct function signature.

The legal cases in which he needs to cast away const could be avoided if the arguments to called functions were appropriately qualified.

- qutebrowser

- vifm

- ranger

- i3

- sway

- tmux

- zathura

- tig

Kitty does not run on Windows.

Sure. This may not be a feasible approach for this case. I'm just pointing out alternative approaches to mitigate this kind of scoping problem in C89. Maybe wrap every use of list_for_each_entry in braces?

    {
        list_for_each_entry(...)
    }

Though C89 does not support declaration of a scoped loop variable like C99 does:

    for(int i = 0; i < 10; i++) {
        // ...
    }

C89 does support declaration of variables at the top of braced blocks whose scope is limited to that block:

    {
        int i;
        for(i = 0; i < 10; i++) {
            // ...
        }
    }

Wouldn't the header need to be explicitly listed as a dependency to prompt it's generation anyway?

> The bad news is that inference rules are not compatible with out-of-source builds. You’ll need to repeat the same commands for each rule as if inference rules didn’t exist. This is tedious for large projects, so you may want to have some sort of “configure” script, even if hand-written, to generate all this for you. This is essentially what CMake is all about. That, plus dependency management.

This isn't a case for CMake. It's a case against POSIX Make. The proposed "portability" and "robustness" of adherence to the POSIX standard are not worth hamstringing the tool. GNU Make is ubiquitous and is leaps and bounds ahead of pure Make.

This one tripped me up too. I'm guessing he meant `a |= b`.