On 12/19/17 9:35 AM, ketmar wrote:
Steven Schveighoffer wrote:
I insist that auto is a storage qualifier
what is the rationale to have `auto` as storage qualifier? except of
keeping it in line with the ancient C feature (and most C programmers
don't even know what `auto` does in C).
Because it's consistent. D says that types are inferred when the type is
missing and there is a storage class specified. Making auto a storage
class fits this definitely perfectly.
i bet that most people are sure that `auto` in D is a type placeholder.
it works like type placeholder, it looks like type placeholder, why
don't make it a type placeholder?
It could be specified that way, but then it's another thing to explain,
which doesn't add any value. The spec can read "The type of a variable
is inferred from the initializer if you specify a storage class" or it
can read "The type of a variable is inferred from the initializer if you
specify a storage class, or if you use 'auto' as the type placeholder."
I don't see a gain there.
ok, i can see *one* place where it won't be consistent: `foo (auto ref
Type v)`. which can be left as a logical exception ('cmon, `enum a =
20;`) is not declaring an enum too, it is used to declare "inline
constant".
auto ref, while a nice feature, is a horrible syntax. It's an exception
no matter what we do!
also:
auto int n = 42;
yay: "Error: variable n storage class 'auto' has no effect if type is
not inferred, did you mean 'scope'?" >
even D compiler knows that `auto` is used as *type* *placeholder*.
'cmon, let's promote it to actual type placeholder!
Another inconsistency that should be fixed (and allowed).
-Steve
