Automatic typing

JS js.mdnq at gmail.com
Thu Jun 27 23:51:39 PDT 2013


On Friday, 28 June 2013 at 00:48:23 UTC, Steven Schveighoffer 
wrote:
> On Thu, 27 Jun 2013 20:34:53 -0400, JS <js.mdnq at gmail.com> 
> wrote:
>
>> Would it be possible for a language(specifically d) to have 
>> the ability to automatically type a variable by looking at its 
>> use cases without adding too much complexity? It seems to me 
>> that most compilers already can infer type mismatchs which 
>> would allow them to handle stuff like:
>>
>> main()
>> {
>>    auto x;
>>    auto y;
>>    x = 3;   // x is an int, same as auto x = 3;
>>    y = f(); // y is the same type as what f() returns
>>    x = 3.9; // x is really a float, no mismatch with previous 
>> type(int)
>> }
>>
>> in this case x and y's type is inferred from future use. The 
>> compiler essentially just lazily infers the variable type. 
>> Obviously ambiguity will generate an error.
>>
>
> There are very good reasons not to do this, even if possible.  
> Especially if the type can change.
>
> Consider this case:
>
> void foo(int);
> void foo(double);
>
> void main()
> {
> auto x;
> x = 5;
> foo(x);
>
> ....
> // way later down in main
> x = 6.0;
> }
>
> What version of foo should be called?  By your logic, it should 
> be the double version, but looking at the code, I can't reason 
> about it.  I have to read the whole function, and look at every 
> usage of x.  auto then becomes a liability, and not a benefit.
>

says who? No one is forcing you to use it with an immediate 
inference. If you get easily confused then simply declare x as a 
double in the first place!

Most of the time a variable's type is well know by the 
programmer. That is, the programmer has some idea of the type a 
variable is to take on. Having the compiler infer the type is 
tantamount to figuring out what the programmer had in mind, in 
most cases this is rather easy to do... in any ambiguous case an 
error can be thrown.

> Coupling the type of a variable with sparse usages is going to 
> be extremely confusing and problematic.  You are better off 
> declaring the variable as a variant.
>

If you are confused by the usage then don't use it. Just because 
for some programmers in some cases it is bad does not mean that 
it can't be useful to some programmers in some cases.

Some programmers what to dumb down the compiler because they 
themselves want to limit all potential risk... What's amazing is 
that many times the features they are against does not have to be 
used in the first place.

If you devise an extremely convoluted example then simply use a 
unit test or define the type explicitly. I don't think limiting 
the compiler feature set for the lowest common denominator is a 
way to develop a powerful language.

You say using a variant type is better off, how? What is the 
difference besides performance? An auto type without immediate 
type inference offers all the benefits of static typing with some 
of those from a variant type...

Since it seems you are not against variant then why would you be 
against a static version, since it actually offers more safety?

In fact, my suggestion could simply be seen as an optimization of 
a variant type.

e.g.,

variant x;
x = 3;


the compiler realizes that x can be reduced to an int type and 
sees the code as

int x;
x = 3;

Hence, unless you are against variants and think they are 
evil(which contradicts your suggestion to use it), your argument 
fails.


More information about the Digitalmars-d mailing list