11

Look at this snippet:

int a;
extern int b;
auto b = a;

Is it well-formed? Clang successfully compiles it, but GCC and MSVC don't.

(This issue has come up when I answered How to declare and define a static member with deduced type?)

Jarod42
  • 203,559
  • 14
  • 181
  • 302
geza
  • 28,403
  • 6
  • 61
  • 135
  • I believe `[dcl.spec.auto]p5` is the critical wording here, feels like the wording should explicitly cover this case but it does not so it ends up being ill-formed. – Shafik Yaghmour Sep 12 '18 at 23:32
  • @ShafikYaghmour: If I think logically, `b` is declared as an `int`. Then, it is defined as an `int` (as `auto` is deduced as `int`). So it should be well-formed. The standard should say otherwise if it wants this to be ill-formed, just like it does so with functions. – geza Sep 12 '18 at 23:39
  • Sure, logically but the standard wording says otherwise ... maybe it is a defect ... not sure yet. I am reaching out to other language lawyers to see but I think my analysis is correct. – Shafik Yaghmour Sep 12 '18 at 23:40
  • If this were ill formed then this would mean that defining global variable with `auto` would be ill formed unless you took extraordinary measures to make sure the extern declaration did not appear in the header when included in the same translation unit as the global definition it declares. Which seems a little bit absurd to me. – Galik Sep 13 '18 at 00:21
  • @Galik I recieved a response from Richard Smith on twitter and he seems to agree that clang is correct. – Shafik Yaghmour Sep 15 '18 at 14:08
  • I am requesting a question merge. – Shafik Yaghmour Sep 15 '18 at 14:10

2 Answers2

5

Clang, GCC, MSVC. (This answer previous stated that all 3 compilers would refuse to build it, but that was incorrect.)

dcl.spec.auto does not address the compatibility of multiple declarations of the same variable when mixing the auto type specifier with other type specifiers. However, it addresses it for function return types:

auto f();
auto f() { return 42; } // return type is int
auto f();               // OK
int f();                // error, cannot be overloaded with auto f()
decltype(auto) f();     // error, auto and decltype(auto) don't match

So my intuition is that this is an oversight in the standard and the behavior is currently unspecified, but if/when it gets specified, there would be precedent to make it illegal. (On the other hand, variables can't be overloaded, so who knows.)

zneak
  • 134,922
  • 42
  • 253
  • 328
  • 1
    What do you mean by this: "variables can't be overloaded, so who knows"? Why could it matter in this case that functions can be overloaded? – geza Sep 12 '18 at 23:25
  • @geza, I feel that there is room for more ambiguity when resolving function types than when resolving variable types. If you feel differently, feel free to discard that comment and assume that your construction is illegal. – zneak Sep 12 '18 at 23:33
3

Tl;DR;

clang is correct, the logic is that this is allowed by [dcl.spec.auto] and to restrict this for deduced return types [dcl.spec.auto]p11 was added otherwise there is no restriction and therefore this is not restricted for the variables case.

See my more complete answer in the duplicate

Community
  • 1
  • 1
Shafik Yaghmour
  • 154,301
  • 39
  • 440
  • 740
  • As already said, I don't see how [dcl.spec.auto]p5 applies here. `auto b = a;` is a valid use of `auto`. – Rakete1111 Sep 14 '18 at 06:19
  • 1
    You can repost on the duplicate and delete this answer if you wish. Alternatively, you can provide a shorter answer here linking to a more generic/broad answer on the duplicate. – Samuel Liew Sep 27 '18 at 06:54