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.
