Automatic typing

[Ary Borenszweig]

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.