Automatic typing

[JS]

On Tuesday, 2 July 2013 at 03:17:58 UTC, Ali Çehreli wrote:
> On 07/01/2013 07:35 PM, JS wrote:
>
> > On Tuesday, 2 July 2013 at 02:15:09 UTC, Andrei Alexandrescu
> wrote:
>
> >> auto a = 2.5; // fine, a is double
> >> ...
> >> a = 3;
> >>
> >
> > No, not under what I am talking about. You can't downgrade a
> type, only
> > upgrade it. a = 3, a is still a float. Using the concept I am
> talking
> > about, your example does nothing new.
> >
> > but reverse the numbers:
> >
> > auto a = 3;
> > a = 2.5;
> >
> > and a is now a float, and your logic then becomes correct
> EXCEPT a is
> > expanded, which is safe.
> >
> > I really don't know how to make it any clearer but I'm not
> sure if
> > anyone understands what I'm talking about ;/
>
> I think I understand. I think I heard either on this or your 
> other thread that function overloading may produce confusing 
> results.
>
> Consider the following program:
>
> void foo(int i)
> {}
>
> void foo(double d)
> {}
>
> void main()
> {
>     auto a = 3;
>     foo(a);
>
>     // Some time later somebody adds the following line:
>     a = 2.5;
> }
>
> If the type of 'a' would suddenly be double from that point on, 
> foo(a) would silently go to a different function. It may be 
> that calling the 'double' overload is the right thing to do but 
> it may as well be that it would be the completely the wrong 
> thing to do.
>

Yes, basically. If one coded for integers then decided to change 
it to doubles and was doing some weird stuff then it could 
completely change the semantics.


> The difference is, today the compiler warns me about the 
> incompatible types. With the proposed feature, the semantics of 
> the program might be different without any warning.
>

Yes, this is the "downside" I see. But there doesn't otherwise 
seem to be any inherent reason why it's a bad idea.

> Of course one may argue that every line must be added very 
> carefully and the unit tests must be comprehensive, etc. Of 
> course I agree but I am another person who does not see the 
> benefit of this proposal. It is never a chore to modify the 
> type of a variable when the compiler warns me about an 
> incompatibility.
>

No one says that the compiler can't warn you still. One could use 
a different keyword from the start. Say *autoscope*. If you use 
that from the get go then you should know full well that strange 
things are possible(and D can still do strange things without 
such a "feature").

Although I am of a different mind set than you are in that I like 
to have more control instead of less.  You can't adapt to change 
if it never happens.  Such a feature would, probably in 98% of 
cases result in something beneficial.  Again, after all, if you 
don't like it don't use it...

I do think it would simplify a few things though. Actually, as I 
mentioned before, there are some use cases where it does reduce 
code complexity. If one is doing something like this:

auto foo(double x) {
   if(typeof(x) == int)
             return "";
         else
             return 2;
     }

then they are asking for trouble.

auto x;
x = foo(1);
x = 2.5 or x = 3 result in x becoming a very different type. (and 
maybe this is essentially the objection of people... but note 
it's not because of x...

auto x = foo();

does the exact same thing.


I believe that having the best tool for the job is what is 
important. But the tools should be available to be used. (This is 
a general statement, I'm not talking about this "feature") When 
you need a bazooka you need a bazooka... to not have one really 
sucks... your pea shooter might do the job 99% of the time and 
that's fine, that's what should be used. But trying to take out a 
tank with a pea shooter isn't going to cut it.