If Eclipse's archaic(!) variable renaming feature for C++ can distinguish between related and unrelated variables which have the same name, you can implement this thing in almost any language.

Eclipse CDT has a real-time static analyzer for the code you're working on though. It's not as naive as it looks from a distance.

Consider this simple C code:

    void inc(int* a, int* b) {
      *a += 1; *b += 2;
    }

Are you adding one to an integer and adding two to another integer, or are you adding three to a single integer?

In other words are the two pointers actually pointing to the same variable? There's no way to know. When you select one pointer, should the other also be highlighted?

But in Rust you cannot have two mutable references to a single variable so the above cannot happen.

Variable renaming is a much much simpler task than this. Of course it is archaic and has existed for a long time.

> In other words are the two pointers actually pointing to the same variable?

This statement is incorrect. You can't have pointers to a variable. You can have pointers to a memory address, and most people would be fine with a tool that is correct up to the level of being unable to differentiate that.

This is a disingenuous redefinition of what the GP is looking for in order to shill Rust.

honestly I'd be ok with a being treated as different than b in this colorized use case. sure, maybe it'd be "bug inducing" or be a subconcious push toward human brains to forget they produced two aliases etc but I think what you're proposing with the c colorizing is impractical and yes I get it, "the tools caused the crash that brought down civilization" but c'mon, if you're still using c, folks have already talked you out of safety nets lol

From thinking about it and merely looking at the gif example... I think you could actually get there via language server alone - at least mostly?

It just highlights parts that interface with a symbol, right? And that's information the language server is supposed to expose.

You'd "just" have to make a x+1 mapping to highlight anything that's touching the symbol

To be clear, I'm just speculating here and not speaking with authority on the topic. It's possible I'm missing something which makes this approach infeasible in practice

You merely explain why you can't copy the implementation strategy.

But that says nothing about providing the same value to the user in other languages via different means.

You merely assume an alternative implementation strategy exists and that it provides the same value to the user.

But that says nothing about whether it actually can exist.

> You merely assume an alternative implementation strategy exists [...]

Huh, where am I making that assumption?

> But that says nothing about whether it actually can exist.

Yes, I expressed no opinion on that.

> Huh, where am I making that assumption?

You didn't, and you didn't express any opinion on whether or not it can exist, either - GP is arguing dishonestly to shill Rust.

Which is really a shame. Rust is a nice enough language that it doesn't need dishonest shilling.

It's not exactly rare to avoid mutability/use a functional style in application code, and even in mutable code, IME aliasing is rare. In some ways Rust's rules are kind of a formalization of what was already good practice in C. Variable scope is also usually small. Turns out things that are easier for the computer to analyze are also easier for people to analyze, so it's long been good practice to structure your code in easy to analyze ways.

Programming languages are built upon mathematically defined and deterministic syntax. You can analyze them with formulae, take concrete and deterministic actions on the syntax tree.

There's no need to unleash a fuzzy and inefficient network on something designed to be deterministic and parseable.

Yes but he was saying other languages weren't in this aspect.

And I said the same as you but that also it could highlight on more abstract things that aren't in the parse tree, I meant things like feature-relatedness etc. These variables are only used for intermediate logging stuff and get greyed out etc.

It's not so much syntax as semantics here. And programming languages are often described and implemented with rather vaguer ideas than fully formally specified semantics. (Even Haskell doesn't have fully formalised semantics.)

Shouldn't be too difficult for C# with Roslyn

Visual Studio is irritatingly doing the opposite. If it detects unused methods/variables it will make them darker (which in general is quite useful), but it also does so when you're still busy creating new methods and just haven't linked them to anything yet.