On 7/1/13 1:15 PM, Walter Bright wrote:
On 7/1/2013 6:39 AM, Ary Borenszweig wrote:
This is not what I am talking about and it seems quite dangerous to have
one variable name masquerade as multiple variables.
Why dangerous?
D already disallows:
int x;
{ float x;
}
as an error-prone construct, so why should it allow:
int x;
float x;
?
Well, those constructs don't even make sense because in the examples I
gave I never say what type I want my variables to be. I let the compiler
figure it out.
I've been programming in Ruby for quite a time and never found it
to be a problem, but an advantage.
What advantage? Does Ruby have a shortage of names for variables? (Early
versions of BASIC only allowed variable names with one letter, leading
to some pretty awful workarounds.)
I'll give you an example:
# var can be an Int or String
def foo(var)
var = var.to_s
# do something with var, which is now guaranteed to be a string
end
I can call it like this:
foo(1)
foo("hello")
If I had to put types, I would end up doing of of these:
1.
void foo(int var) {
foo(to!string(var))
}
void foo(string var) {
// do something with var
}
2.
void foo(T)(T var) {
string myVar;
static if (is(T == string)) {
myVar = var;
} else if (is(T == int)) {
myVar = to!string(var)
} else {
static assert(false);
}
// do something with myVar
}
Both examples are ugly and verbose (or, at least, the example in
Ruby/Crystal is much shorter and cleaner). The example I give is very
simple, I can reuse a var which *has the same meaning* for me when I'm
coding and I don't need to come up with a new name.
It's not that Ruby has a shortage of names. It's just that I don't want
to spend time thinking new, similar names, just to satisfy the compiler.
(And if you are worried about efficiency, the method "#to_s" of String
just returns itself, so in the end it compiles to the same code you
could have written manually like I showed in D)
Show me an example where this is dangerous (the pointer example gave
by Walter
is not valid anymore since it has a fix).
I'm actually rather sure that one can come up with rule after rule to
'fix' each issue, but good luck with trying to fit all those rules into
some sort of comprehensible framework. Consider what happened to C++
when they tried to fit new things into the overloading rules - the rules
now span multiple pages of pretty arbitrary rules, and practically
nobody understands the whole. What people do is randomly try things
until it seems to do the right thing for them, and then they move on.
And all this for what - nobody has come up with a significant reason to
support this proposal. I see post after post in this thread trying to
make it work, and nothing about what problem it solves.
Exactly, because in D you need to specify the types of variables. And
that goes against inferring a variable's type from its usage (which is
different from inferring it from its initializer).
I'm also against this proposal. I'm just saying that in D it's not
feasible, and if you want to make it work you'll have to change so many
things that you'll end up with a different language.
