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.

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.

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.

Ali

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.

On 7/1/13 7:35 PM, JS wrote:
> On Tuesday, 2 July 2013 at 02:15:09 UTC, Andrei Alexandrescu wrote:
>> On 7/1/13 6:29 PM, JS wrote:
>>> Would would be nice is an experimental version of D where would could
>>> easily extend the language to try out such concepts to see if they truly
>>> are useful and how difficult to implement. e.g., I could attempt to add
>>> said "feature", it could be merged with the experimental compiler, those
>>> interested can download the compiler and test the feature out... all
>>> without negatively affecting D directly. If such features could be
>>> implemented dynamically then it would probably be pretty powerful.
>>
>> I don't think such a feature would make it in D, even if the
>> implementation cost was already sunken (i.e. an implementation was
>> already done and one pull request away).
>>
>> Ascribing distinct objects to the same symbol is a very core feature
>> that affects and is affected by everything else. We'd design a lot of
>> D differently if that particular feature were desired, and now the
>> fundamentals of the design are long frozen. For a very simple example,
>> consider:
>>
>> 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 ;/

You can definitely assume you are being well understood. That's going to break a lot of code because of e.g. calls to overloaded functions in between changes of type.

Just drop this. Not only it won't make it into D, it's also not particularly interesting.


Andrei

Steven Schveighoffer wrote:
> There are very good reasons not to do this, even if possible.  Especially if the type can change.

+1

This sort of inference can only lead to problems down the line, IMO.

On Saturday, 29 June 2013 at 03:20:27 UTC, JS wrote:
> I don't disagree with you and I'm not saying auto is not useful. IMO though, auto is almost all convenience and very little to do with solving errors.
>
> A very simple use case is:
>
> auto x = 0;
> ...
> x = complex(1, 1) + x;
>
> which obviously is an error.

Let me expand the example with this:

auto x = 0;
complex y;
...
x = complex(1, 1) + x; // ouch, I meant the next line!
y = complex(1, 1) + x;

Personally, I appreciate the strengths of static typing here, forcing me to choose which of the two behaviors I meant instead of silently picking one of them.

Ivan Kazmenko.