Johan Granberg wrote:
BCS wrote:
Hello Andrei,
I think "with" is a very dangerous feature due to the way it hides
symbols. It essentially makes the feeblest attempt at modular
reasoning utterly impossible:
int x, y;
with (whatever)
{
y += x;
++x;
}
Maintenance of any type that is being used with "with" becomes a very
dangerous proposition because it can silently change meaning of code.
I'd be willing to go the half way solution of making accessing a shadowing
symbol an error, resulting in (loudly) not being able to access either.
I think this solution is a good idea but that removing or restricting
anything more regarding with is a bad idea as others have pointed out.
I'm using with quit a lot and it was one of thous things that attracted me
to D (I get the feeling that D has a quite pragmatic way of looking at
language features, if it's usefull lets have it unless it's harmfull to
other parts of D, sort of.).
I personally still think it's a bad feature because it introduces
long-distance coupling between symbols defined in two different places,
both distinct from the place where the statement is used! Consider:
import wyda; // defines symbol write
import geeba; // defines struct S { ... }
void main()
{
S s;
with (s) {
write(5);
}
}
Machiavelly would jump in joy at such code. What did I achieve? I saved
a few "s.". What did I lose? The ability so say anything, but absolutely
anything on what the code does. If S changes, the code may compile and
run, yet doing something completely different. The dependency is not
between the code as seen and wyda or geeba. It's between wyda and geeba,
intermediated by "with"! I mean, if one _planned_ to design a maximally
damaging language feature one couldn't come up with something better.
And for what? Because you find it convenient to not type "s." a few
times or just go in the blessed object and define a member? Is _this_
what makes or breaks your productivity? And are you willing to pay the
ability to do the feeblest reasoning about your code for that doubtful
benefit?
This is so against every single good notion of language design, I kid
you not I feel my blood pressure rising only as I think of it. No amount
of "but I find it useful" can protect this awful non-feature. It should
be taken in the back and shot in the head, no trial. Shoot the lawyer
too if it has one.
On a similar note, Andrei, what is this spree of removing features? Ok some
are obviously bad, imaginary types for example, but why remove other stuff
such as commplex and with?
TDPL is coming out. This is quite literally the last chance to shed some
old skin. Complex as a built-in does nothing of interest to anyone
except a cute syntax for literals that nobody uses (how many remarkable
complex literals could you imagine?) About "with"... see above before I
die of a heart attack.
The baroque "!<>=" operators became much more attractive since Walter
said he's considering making them overloadable.
On the other hand new features are coming, which I believe are "good
skin". Narrowing integral conversions will go. Walter is working on a
very cool scheme for inferring the range of expressions that makes casts
unnecessary in many cases. Casts are a plague not only for safe code,
but also for generic code that wants to be scalable and change-robust.
The ease with which C and C++ allow losing state and the drowning
necessity of integral casts in Java or C# are both extremes that I'm
happy to see D avoid.
Final switch works with enums and forces you to handle each and every
value of the enum. Regular switch gets ranged cases by the syntax case
a: .. case b: (I've always thought switch would be greatly helped by that).
Static foreach might be making it too.
Andrei
