1

I was wondering why it is not possible to omit the auto keyword in some/all cases entirely, e.g.

int main()
{
  [](auto x){}(10); // why this?
  [](x){}(10); // and not this?

  auto x = 10;
  x = 10;
}

Is there a problem with ambiguity or something similiar? Or was it simple a design choice?

Yamahari
  • 1,926
  • 9
  • 25
  • You'd have to ask somebody on the standards committee, since all most of us can do is speculate. – Stephen Newell Jun 03 '20 at 20:10
  • 3
    `auto x = 10;` variable definition and initialization. `x = 10;` assignment of existing variable. Totally different things. – user4581301 Jun 03 '20 at 20:10
  • always to don't break retro compatibility and compilation ambiguity – Alberto Sinigaglia Jun 03 '20 at 20:11
  • It is, IMO, a plus point of C / C++ that you must declare a variable before you can use it. Think of the mistakes you might make if this wasn't true. – Paul Sanders Jun 03 '20 at 20:12
  • 1
    Half of your question is [answered here](https://stackoverflow.com/q/50483204/734069) – Nicol Bolas Jun 03 '20 at 20:13
  • @user4581301 why not treat "x = 10" as declaring x if x has not been declared and otherwise as assignment – Yamahari Jun 03 '20 at 20:13
  • 1
    @Yamahari I would not like this change. If I write `x = 10;` without `x` being defined, it lets me know I made a mistake. Either I forgot to write a type (even if it's `auto`) or I misspelled an identifier. It's worth the hassle in the first case to protect myself from the second. – François Andrieux Jun 03 '20 at 20:15
  • If you write `x = 10;` and that implicitly declares the local variable, then someone else adds a global `int x = 10;`, does your local `x` now refer to the global `x`? What if you had local `frog = 10;` and later in same routine type `forg = 11;` by mistake, the compiler wouldn't be able to help you. (Well, not **you**, you never make typos. I mean **me**.) – Eljay Jun 03 '20 at 20:17
  • 2
    Unfortunetly [abbreviated lambdas](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0573r0.html) was rejected. – NathanOliver Jun 03 '20 at 20:19

1 Answers1

6

Consider this:

 struct x {};

 [](x){}(10);

Is that a lambda with an unnamed argument of type x (as per the current language spec) or is it am argument named x of deduced type (as per your suggestion)? Your suggested syntax is ambiguous with the pre-existing syntax of function parameter declarations.

x = 10;

This is even more problematic because it is indistinguishable from assignment. Someone writing this might be attempting to define a variable (your suggestion), but it can just as well be assignment of an existing variable depending on context. C++ has too much syntactical ambiguity (for the programmer) as it is. We should avoid adding more.

eerorika
  • 232,697
  • 12
  • 197
  • 326
  • I see, but in that case it could be a compile-time error indicating the ambiguity, couldn't it? – Yamahari Jun 03 '20 at 20:17
  • 4
    @Yamahari But it is not an ambiguity now. Introducing compile error to a previously well-formed program is something that the committee, and us users of the language want to avoid except in cases where the well-formed code is broken. – eerorika Jun 03 '20 at 20:19
  • 2
    @Yamahari that's how lambda function syntax works. Nothing to discuss here. We could have a long discussion about why it's `int x = 10;` and not `x : int = 10;` or some other way, but that's not useful for anybody. – Aykhan Hagverdili Jun 03 '20 at 20:27