> It’s surprising to me that Go made unused imports an error, and yet missed this far more critical one. So close!
The most egregious to me has always been that unused imports are an error but variable shadowing is not.
Even in languages with dynamic side-effecting imports (like Ruby or Python) I've never seen a bug caused by an unused import. Not so for shadowing (don't get me wrong, it's a convenient feature, but if you're going to remove this sort of things because reasons it's a much bigger pitfall than unused imports).
Variable shadowing is actually a pretty clever thing that I'd like to see in other languages.
For example I often write code like this in Java:
String ageString = request.getParameter("age");
int ageInt = parseInt(ageString);
because I can't re-use name `age` twice and forced to distinguish between those names.
Now I agree with you about imports. I often want to comment a line and run program. Now I have to comment a line, run a program, encounter compilation error, find import, comment that import, run again. And uncomment two lines later. With Java my IDE optimizes import and removes all unused imports when I'm commiting my code. While I'm working on my code, I'm absolutely fine with any warnings. I would say even more: back then when I used Eclipse, it had awesome ability to compile even code with errors. This code just throws exception on runtime. But if I'm not really interested in that snnippet and working on other part, I can run it just fine. Probably that feature is the only thing that I'm missing from Idea.
> Variable shadowing is actually a pretty clever thing that I'd like to see in other languages.
Shadowing exists in most languages, the biggest difference being the allowed scope relationships between the shadower and the shadowee: most languages allow inter-function and inter-block shadowing (if they have actual block-level scope so e.g. not Python).
Intra-block shadowing is a much rarer feature, and one which Go doesn't have.
Indeed, because semantically there is a syntactically implicit scope for every let binding. For example, in that case, the outer a is dropped after the inner a, just as if the second a had been inside of a block. There may be multiple syntactic ways to introduce a new scope.
I really like this syntax. I wonder if it has ever been proposed for Rust? It should be compatible with the existing semantics and could be phased in and then made mandatory in a new "edition".
There is already a “let” to show you that a variable is being created, adding more verbosity to a feature that, in some sense, is about removing verbosity kinda misses the point, in my opinion.
That said, never say never, but if I was a betting kind of person, I’d bet against it ever being accepted.
The most egregious to me has always been that unused imports are an error but variable shadowing is not.
Even in languages with dynamic side-effecting imports (like Ruby or Python) I've never seen a bug caused by an unused import. Not so for shadowing (don't get me wrong, it's a convenient feature, but if you're going to remove this sort of things because reasons it's a much bigger pitfall than unused imports).