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.
