nsf: > Well, D currently says I can't shadow variables:
Right, that's a third way to shadow variables that D forbids, thank you. But in my post I've shown other kinds of shadowing that currently D accepts. Shadowing global variables has caused some problems in my C code. One good commercial C lint lists all such cases with a warning. > which pisses me off personally. It's such a handy feature. It's a handy anti-feature, good source of bugs. Style guides suggest to rename one of them. If I see production C/C++ code that does that, I rename one of the two variables. In Haskell in your situation you are allowed to use x and x'. > And there is exactly one way to solve your problem which comes in two parts: Surely there are some alternative ways to solve this problem, SPARK and Java doesn't use your solution. > 1. Don't violate the rule: "one or two screens of text per function". > 2. Keep the low number of variables in a function, people say it should > be close to seven. I like to add a third rule, for D code: 3. Use pure functions everywhere possible. This avoids the shadowing problem. But: 1) Old C code translated to D often doesn't follow your rules, unfortunately. 2) I have had colleagues that don't always follow your rules. 3) Even good codebases sometimes have longer functions. You find them even in the C sources of Python. 4) Even if you always follow your two rules, you are able to shadow a global (or outer) variable still, and 20 lines later sometimes you think that you are using the global variable, while you are modifying the local one. I have seen this happen even in code written by expert programmers, and it causes problems. > /me wants to be able to shadow his variables everywhere Good luck :-) Bye and thank you for your comments, bearophile
