I don't think this is the best option, there could be very hard bugs or performance cliffs. I think I'd rather have an explicit opt-in, rather than the abstraction changing underneath me. Have my IDE scream at me and make me consider if I really need the opt-in, or if I should restructure.

Although I do agree with the sentiment of choosing a construct and having it optimize if it can. Reminds me of a Rich Hickey talk about sets being unordered and lists being ordered, where if you want to specify a bag of non-duplicate unordered items you should always use a set to convey the meaning.

It's interesting that small hash sets are slower than small arrays, so it would be cool if the compiler could notice size or access patterns and optimize in those scenarios.

Right, sql optimizers are a good example - in theory it should "just know" what is the optimal way of doing things, but because these decisions are made at runtime based on query analysis, small changes to logic might cause huge changes in performance.

I use Swift for work. The compiler tell you this. If a mutable variable is never mutated it suggests making it non-mutable. And vice versa.

As will Typescript, at least using Biome to lint it does.

eslint has this too: https://eslint.org/docs/latest/rules/prefer-const

My very minor complaint about TypeScript is you use to use `const` which is 2 additional letters.

Seriously though, I do find it slightly difficult to reason about `const` vars in TypeScript because while a `const` variable cannot be reassigned, the value it references can still be mutated. I think TypeScript would benefit from more non-mutable values types... (I know there are some)

Swift has the same problem, in theory, but it's very easy to use a non-mutable value types in Swift (`struct`) so it's mitigated a bit.

Yup, it's pretty great. You get into the habit of suspiciously eyeing every variable that's not a constant.

I don’t have any useful ideas here but if you make a linter for this sort of thing, I suggest calling it “mutalator.”

Clang-tidy's misc-const-correctness warns for this. Hook it up to claude code and it'll const all non mutated mutables.

Your IDE probably supports this as an explicit action. JetBrains has a feature that can find all reads and writes to a variable

It also has the ability to style mutated variables differently.

Yes, depending on your highlighting scheme. Not every highlighting scheme shows this by default, unfortunately.

To me, this seems initially like some very minor thing, but I find this very helpful working with non-trivial code. For larger methods you can directly discern whether a not-as-immutable-declared variable behaves immutable nonetheless.

If you write in erlang, emacs does this by default ;)

In my IntelliJ (a recent version), if I write a small Java function like this:

    private static void blah()
    {
        final int abc = 3;
        for (int def = 7; def < 20; ++def)
        {
            System.out.print(def);
        }
    }

The variable 'def' is underlined. Mouse-over hint shows: 'Reassigned local variable'. To be clear, 'abc' is not underlined. When I write Java, I try to use the smallest variable scopes possible with as much final (keyword) as possible. It helps me to write more maintainable code, that is easier to read.

1st) you use ++def in a loop, don't be weird; 2nd) if 'abc' is to be used in the loop body, define in the loop, e.g. for (int def = 7, abc =3; ...); 3rd) this is an IntelliJ bug - both 'def' and 'abc' in the sample are always defined.

3) looks like you read 'underlined' as 'undefined'

true that, thanks!

the only thing that is weird is your lack of understanding temporary variables

perhaps... yet, Java doesn't have a definition for temporary variables

    > you use ++def in a loop, don't be weird

I come from a C++ background where it is always advised to use ++i instead of i++. It's just a habit. Does it stress you to read ++i over i++?

>Does it stress you to read ++i over i++?

Of course not, I do use both. Admittedly i++ is a lot more common in Java, and for loops i++ is the standard idiom. Not using the standard idiom usually implies less practice, e.g. str.indexOf('x') < 0 is the standard one, not == -1. Even the backwards iteration is a postfix subtraction::

  for (int i = array.length; i-- > 0;) doStuff(array[i]);

As an aside, you might also enjoy the inline inferred annotations.

https://www.jetbrains.com/help/idea/annotating-source-code.h...

Seeing @NotNull in there even if the author hasn't specifically written that can help in understanding (and not needing to consider) various branches.

This works in RustRover as well! Super useful.

Rust's type system specifically facilitates more powerful tools: https://github.com/willcrichton/flowistry

Could Pylint help? It has atleast check for variable redefinition: https://pylint.pycqa.org/en/latest/user_guide/messages/refac...

For type only though.