Automatic typing

[JS]

On Saturday, 29 June 2013 at 02:05:35 UTC, Walter Bright wrote:
> On 6/28/2013 6:48 PM, JS wrote:
>> What was the use case for auto that got in into the language?
>
> In code where the type of the initializer would change, and if 
> the type of the variable was fixed, then there would be an 
> unintended implicit conversion. The other use case was 
> voldemort types. Such patterns are commonplace, and a source of 
> error and inconvenience without auto. auto appears in various 
> forms in other languages, and is almost universally lauded as 
> worthwhile.
>
> These cases don't apply to this proposal, nor do I know of its 
> successful adoption in another language.
>
> It's not a matter of finding reasons not to implement it. It's 
> finding reasons TO implement it. Language features do not have 
> zero cost - some benefit has to offset it.


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.

By having auto use forward inferencing we can avoid such errors. 
It's obvious that x was intended to be a complex variable. Having 
auto look forward(or using a different keyword) reduces code 
refactoring and improves on the power of auto.

for example suppose we use instead

auto x = pow(2, 10);

where pow returns a real. In this case x is still the wrong type. 
So we always have to know the "final" supertype anyways... I'm 
just proposing we let the compiler figure it out for us if we 
want.

But because some types are supertypes of others it is entirely 
logical that they be extended when it is obvious the are being 
used as such.

To see why this is even more useful, suppose we had such code 
above but now want to refactor to use quaternions. In this case, 
the line x = complex(1,1) + x is becomes invalid too and requires 
fixing(or the auto x line has to be fixed). If we allowed auto x; 
to easily see that it is suppose to be a quaternion then that 
line does not have to be fixed and everything would work as 
expected.


So the real question is, is it error prone to allow the compiler 
to deduce what supertype a variable really is? I do not think it 
is a problem because ambiguity results in an error and warnings 
could be given when a variable type was upgraded to a super type.

At some point, if flow analysis is ever added, auto would be a 
natural bridge to it.

another useless case is

auto someflag;
static if (__cpu == 3)
    someflag = "amdx64"
else
    someflag = false;

which allows a sort of static variant type. (which could be 
gotten around if a static if conditional expression, e.g.,

static auto someflag = (__cpu == 3) ?? "amdx64" : false; )

The above may make it easier in some cases for configuration code.


The biggest benefit I can immediately see comes from using 
mixins. In this case we can always have a variable select the 
appropriate type.

e.g.,

mixin template Foo() { ((...) ?? int : float) func() { } }  // 
func is of type int or float depending on the condition ...

class Bar {
     auto x; // possibly auto x = default(typeof(func)); but 
possibly error prone due to refactoring if line order matters
     mixin Foo;
     static Bar() { x = default(typeof(func)); }
}

note that x's type is deduced at compile time to be the 
appropriate type corresponding to the mixin used. Because x's 
type does not have to be immediately known we can specify it 
implicitly later on without ever having to know the return types 
of the mixins.

In this case Bar acts like a templated class but isn't(or is a 
sort of statically templated class so to speak)

Such classes would be useful for versioning where the user of the 
class is oblivious to the types used in the class and does not 
need to specify a type parameter.

e.g., The Bar class above could use int for a more performant 
version of the program and float for a more precise version. The 
use of auto would completely or near completely eliminate having 
to deal with which one is being used.

In any case I can't specify any super duper use case because I 
don't know any.