[Hublium]

> [C++] also had type inference very early on, but the developers of the mid-80s were not quite ready for that and Bjarne Stroustrup was pressured into removing auto, until it was added back to C++11.

Does anybody have background information on this claim? Was there actually a working compiler with it back then or was it just some proposal paper at the time?

[slaymaker1907]

I found a post claiming it was used in B and C to specify a data type stored on the stack.

https://stackoverflow.com/a/8272497/7608007

[colonwqbang]

Not "was", "is"! auto is the opposite of static in a way. Since it's the default method of storage for local variables, it's very rare to specify it explicitly. C++ just took this C keyword and made it mean something completely different.

[ajb]

That's exactly what it means. Nobody used to use the keyword because it was the default anyway. The new meaning is not the same.

[pjmlp]

C23 is considering following C++ footsteps and repurpose auto as well.

[colonwqbang]

I hope they don't, at the very least we can afford to choose a new keyword. Even if auto was infrequently used, it's no good to silently change the meaning of existing valid programs.

[foldr]

Would it change the meaning of existing valid programs? C's "type inference" algorithm is to assume that everything is an int by default. So

    auto x = 7;

is equivalent to

    auto int x = 7;

which is equivalent to

    int x = 7;

(since "auto" is the default storage class). If the C standard folks do things right, then the only change will be to allow some previously invalid code like the following:

    auto str = "foo";

Such code will compile on a C compiler (hopefully with a warning!) but won't have a defined behavior. I guess a more problematic case would be

    auto x = 9999999999999L;

Where the value will be truncated in C but will be inferred as a long in C++ (assuming typical sizes for int and long int). Again, though, I am not sure if truncation of signed constants has a defined behavior in the standard.

[colonwqbang]

A simple example would be

  auto pi = 3.14;
  double result = 2 * pi;
  printf("the circumference of the unit circle is %g\n", result);

When interpreted as C89 program, this computes the value 6. Compiled with a C++ compiler it computes 6.28. This is exactly due to that both languages have an auto keyword, but they mean different things.

This situation is perhaps not so likely to occur in real usage, but I think it could and should have been avoided.

[foldr]

Ah good point. I was forgetting that implicit conversion from double to int is defined.

[pjmlp]

It is part of N2891

"Type inference for variable definitions and function returns"

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p230...

Enjoy some of the other proposals,

"Basic lambdas for C"

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p230...

"Improve type generic programming"

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p230...

"Type-generic lambdas"

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p230...

"Revise spelling of keywords"

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p231...

"Make false and true first-class language features"

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p231...

Naturally at this point one could ask why not just use C++ instead, well that is what happens when a language group is so firmly against moving upwards, but still wants the features on their language.

Naturally missing from the list are any kind of improvements to string or arrays alternatives, as usual.

[Koshkin]

Ugh. auto is so much worse than var (as in C#, for instance). But I am grateful they didn't choose register instead.

[pjmlp]

The working compiler was CFront.

Look for Bjarne talks at CppCon on the subject of language evolution, he has mentioned it on a couple of them.