On Sunday, 24 November 2013 at 15:01:34 UTC, ilya-stromberg wrote:
On Sunday, 24 November 2013 at 14:50:28 UTC, Maxim Fomin wrote:
This is identifiers shadowing issue. In best case you could
not define boolean f, so the problem would not arise in a
first place.
Yes, I agree that it's also can be identifiers shadowing issue.
But we allow code like this:
class Foo
{
int i;
this(int i)
{
this.i = i;
}
}
Anyway, many artifical examples can be provided which shows
that some features behave in unexpected ways which is not a
reason that they are bad.
I repeat, this is REAL LIFE example. I just reduce it because
it have unnecessary details for this case.
Many people complain about language features which are really
broken, misfunctiong, or both. Sometimes they point out on cases
like:
assert("Unexpected error occured");
which do not show feature failure, but language can be improved
by rejecting or at least warning in such cases. However your case
class Foo
{
}
class Bar
{
Foo f;
void bar()
{
//variable was wrongly commented here
//bool f = true;
if(f)
{
//Oops!
}
}
}
has nothing to do with either of these two types of
defficiencies. No way compiler could guess that you have bool f
in mind. There is no way to improve the language because it
requires blocking class to bool conversion in boolean context
which is pretty nice feature and there are plenty of code which
has to be broken.
