3 ms·
As I understand it, go has some special handling for this scenario because its so prevalent which special cases reassignment. The linked article touches on it
by JamesSwift 1y ago
As I understand it, go has some special handling for this scenario because its so prevalent which special cases reassignment. The linked article touches on it
> There are exceptions to this rule in areas with high “foot traffic”: assignments come to mind. Ironically, the ability to redeclare a variable in short variable declarations (:=) was introduced to address a problem that arose because of error handling: without redeclarations, sequences of error checks require a differently named err variable for each check (or additional separate variable declarations)
- Pxtl 1y ago... I thought Go's whole deal was that you give up the expressiveness and power of overdesigned languages for simple, clean, "only one way to do it" semantics. That "special cases reassignment" where ':=' is sometimes a shadowing declaration and sometimes a reassignment sounds like the opposite of that.
- homebrewer 1y agoThe language is full of gotchas like that, you're expected to use the tooling to guardrail yourself, because having a proper type system or coherent syntax is "too complicated" (while learning dozens of patterns and weird tricks apparently isn't). go vet and this massive collection of linters bundled into a single binary are very popular: https://golangci-lint.run https://golangci-lint.run linters will warn you of accidental shadowing, among many other things.
- masklinn 1y ago> That "special cases reassignment" where ':=' is sometimes a shadowing declaration and sometimes a reassignment sounds like the opposite of that. FWIW it is never a shadowing declaration. It is at least one non-shadowing declaration plus any number of reassignments. The fun part is the tendency to keep reassigning to `err` makes the unused variable largely useless, so it’s just there to be a pain in the ass, and your need a separate lint anyway.