Automatic typing

[JS]

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 ;/



> By the proposed rule a will become an entirely different 
> variable of type int, and the previous double variable would 
> disappear. But current rules dictate that the type stays 
> double. So we'd either have an unthinkably massive breakage, or 
> we'd patch the language with a million exceptions.
>
> Even so! If the feature were bringing amazing power, there may 
> still be a case in its favor. But fundamentally it doesn't 
> bring anything new - it's just alpha renaming; it doesn't 
> enable doing anything that couldn't be done without it.
>
>

Expanding a type is always valid because it just consumes more 
memory. A double can always masquerade as an int without issue 
because one just wastes 4 bytes. An int can't masquerade as a 
double because any function think uses it as a double will cause 
corruption of 4 bytes of memory.

(I'm ignoring that a double and int use different cpu 
instructions. This is irrelevant unless we are hacking stuff up)


The simplest example I can give is:

auto x = 2;
x = 2.5;

x IS a double, regardless of the fact that auto x = 2; makes it 
look like an int BECAUSE that is how auto currently is 
defined(which might be the confusion).

The reason is, that the compiler looked at the scope for all 
assignments to x and was able to determine automatically that x 
needed to be a double.


I'll give one more way to look at this, that is a sort of 
inbetween but necessary logical step:

We have currently that auto looks at the immediate assignment 
after it's keyword to determine the type, correct?

e.g.,

auto x = 3;

What if we allow auto to look at the first assignment to x, not 
necessarily the immediate assignment, e.g.:

auto x;
x = 3;

(should be identical to above)

or

auto x;
.... (no assignments to x)
x = 3;

All this should be semantically equivalent, correct? To me, the 
last case is more powerful since it is more general. Of course, 
one could argue that it makes it more difficult to know the type 
of x but I doubt this would be a huge issue.