Is it well-formed, if I redefine a variable as auto, and the deduced type is the same? [duplicate]

Clash Royale CLAN TAG#URR8PPP
up vote
11
down vote
favorite
This question already has an answer here:
Does a declaration using âautoâ match an extern declaration that uses a concrete type specifier?
2 answers
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?)
c++ language-lawyer auto variable-declaration
marked as duplicate by M.M
StackExchange.ready(function()
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();
);
);
);
Sep 13 at 0:32
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
 |Â
show 1 more comment
up vote
11
down vote
favorite
This question already has an answer here:
Does a declaration using âautoâ match an extern declaration that uses a concrete type specifier?
2 answers
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?)
c++ language-lawyer auto variable-declaration
marked as duplicate by M.M
StackExchange.ready(function()
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();
);
);
);
Sep 13 at 0:32
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
I believe[dcl.spec.auto]p5is 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 at 23:32
@ShafikYaghmour: If I think logically,bis declared as anint. Then, it is defined as anint(asautois deduced asint). 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 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 at 23:40
If this were ill formed then this would mean that defining global variable withautowould 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 at 0:21
@Galik I recieved a response from Richard Smith on twitter and he seems to agree that clang is correct.
â Shafik Yaghmour
Sep 15 at 14:08
 |Â
show 1 more comment
up vote
11
down vote
favorite
up vote
11
down vote
favorite
This question already has an answer here:
Does a declaration using âautoâ match an extern declaration that uses a concrete type specifier?
2 answers
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?)
c++ language-lawyer auto variable-declaration
This question already has an answer here:
Does a declaration using âautoâ match an extern declaration that uses a concrete type specifier?
2 answers
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?)
This question already has an answer here:
Does a declaration using âautoâ match an extern declaration that uses a concrete type specifier?
2 answers
c++ language-lawyer auto variable-declaration
c++ language-lawyer auto variable-declaration
edited Sep 12 at 23:04
Jarod42
108k1297172
108k1297172
asked Sep 12 at 22:41
geza
10.2k22465
10.2k22465
marked as duplicate by M.M
StackExchange.ready(function()
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();
);
);
);
Sep 13 at 0:32
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by M.M
StackExchange.ready(function()
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();
);
);
);
Sep 13 at 0:32
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
I believe[dcl.spec.auto]p5is 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 at 23:32
@ShafikYaghmour: If I think logically,bis declared as anint. Then, it is defined as anint(asautois deduced asint). 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 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 at 23:40
If this were ill formed then this would mean that defining global variable withautowould 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 at 0:21
@Galik I recieved a response from Richard Smith on twitter and he seems to agree that clang is correct.
â Shafik Yaghmour
Sep 15 at 14:08
 |Â
show 1 more comment
I believe[dcl.spec.auto]p5is 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 at 23:32
@ShafikYaghmour: If I think logically,bis declared as anint. Then, it is defined as anint(asautois deduced asint). 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 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 at 23:40
If this were ill formed then this would mean that defining global variable withautowould 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 at 0:21
@Galik I recieved a response from Richard Smith on twitter and he seems to agree that clang is correct.
â Shafik Yaghmour
Sep 15 at 14:08
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 at 23:32
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 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 at 23:39
@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 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 at 23:40
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 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 at 0:21
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 at 0:21
@Galik I recieved a response from Richard Smith on twitter and he seems to agree that clang is correct.
â Shafik Yaghmour
Sep 15 at 14:08
@Galik I recieved a response from Richard Smith on twitter and he seems to agree that clang is correct.
â Shafik Yaghmour
Sep 15 at 14:08
 |Â
show 1 more comment
2 Answers
2
active
oldest
votes
up vote
5
down vote
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.)
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 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 at 23:33
add a comment |Â
up vote
3
down vote
Update clang is correct
I asked this question on twitter and the response I received from Richard Smith was as follows:
Not a defect, it's intentional that this restriction applies only to deduced return types and not to variable types. For variables, it's just a convenience shorthand, but return type deduction affects something more fundamental about functions (and especially function templates).
So 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.
Original
Currently [dcl.spec.auto] does not seem to cover this case explictly but it does say in [dcl.spec.auto]p5:
A program that uses auto or decltype(auto) in a context not explicitly allowed in this subclause is ill-formed.
and we can see it makes a similar case for functions ill-formed in [dcl.spec.auto]p11:
Redeclarations or specializations of a function or function template
with a declared return type that uses a placeholder type shall also
use that placeholder, not a deduced type. Similarly, redeclarations or
specializations of a function or function template with a declared
return type that does not use a placeholder type shall not use a
placeholder. [ Example:auto f();
auto f() return 42; // return type is int
auto f(); // OK
int f(); // error, cannot be overloaded with auto f()
....
So although this could use clarification as currently worded it feels like gcc is correct and this is ill-formed.
As already said, I don't see how [dcl.spec.auto]p5 applies here.auto b = a;is a valid use ofauto.
â Rakete1111
Sep 14 at 6:19
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 at 6:54
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
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.)
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 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 at 23:33
add a comment |Â
up vote
5
down vote
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.)
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 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 at 23:33
add a comment |Â
up vote
5
down vote
up vote
5
down vote
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.)
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.)
edited Sep 12 at 23:02
answered Sep 12 at 22:55
zneak
94.3k30201271
94.3k30201271
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 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 at 23:33
add a comment |Â
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 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 at 23:33
1
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 at 23:25
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 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 at 23:33
@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 at 23:33
add a comment |Â
up vote
3
down vote
Update clang is correct
I asked this question on twitter and the response I received from Richard Smith was as follows:
Not a defect, it's intentional that this restriction applies only to deduced return types and not to variable types. For variables, it's just a convenience shorthand, but return type deduction affects something more fundamental about functions (and especially function templates).
So 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.
Original
Currently [dcl.spec.auto] does not seem to cover this case explictly but it does say in [dcl.spec.auto]p5:
A program that uses auto or decltype(auto) in a context not explicitly allowed in this subclause is ill-formed.
and we can see it makes a similar case for functions ill-formed in [dcl.spec.auto]p11:
Redeclarations or specializations of a function or function template
with a declared return type that uses a placeholder type shall also
use that placeholder, not a deduced type. Similarly, redeclarations or
specializations of a function or function template with a declared
return type that does not use a placeholder type shall not use a
placeholder. [ Example:auto f();
auto f() return 42; // return type is int
auto f(); // OK
int f(); // error, cannot be overloaded with auto f()
....
So although this could use clarification as currently worded it feels like gcc is correct and this is ill-formed.
As already said, I don't see how [dcl.spec.auto]p5 applies here.auto b = a;is a valid use ofauto.
â Rakete1111
Sep 14 at 6:19
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 at 6:54
add a comment |Â
up vote
3
down vote
Update clang is correct
I asked this question on twitter and the response I received from Richard Smith was as follows:
Not a defect, it's intentional that this restriction applies only to deduced return types and not to variable types. For variables, it's just a convenience shorthand, but return type deduction affects something more fundamental about functions (and especially function templates).
So 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.
Original
Currently [dcl.spec.auto] does not seem to cover this case explictly but it does say in [dcl.spec.auto]p5:
A program that uses auto or decltype(auto) in a context not explicitly allowed in this subclause is ill-formed.
and we can see it makes a similar case for functions ill-formed in [dcl.spec.auto]p11:
Redeclarations or specializations of a function or function template
with a declared return type that uses a placeholder type shall also
use that placeholder, not a deduced type. Similarly, redeclarations or
specializations of a function or function template with a declared
return type that does not use a placeholder type shall not use a
placeholder. [ Example:auto f();
auto f() return 42; // return type is int
auto f(); // OK
int f(); // error, cannot be overloaded with auto f()
....
So although this could use clarification as currently worded it feels like gcc is correct and this is ill-formed.
As already said, I don't see how [dcl.spec.auto]p5 applies here.auto b = a;is a valid use ofauto.
â Rakete1111
Sep 14 at 6:19
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 at 6:54
add a comment |Â
up vote
3
down vote
up vote
3
down vote
Update clang is correct
I asked this question on twitter and the response I received from Richard Smith was as follows:
Not a defect, it's intentional that this restriction applies only to deduced return types and not to variable types. For variables, it's just a convenience shorthand, but return type deduction affects something more fundamental about functions (and especially function templates).
So 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.
Original
Currently [dcl.spec.auto] does not seem to cover this case explictly but it does say in [dcl.spec.auto]p5:
A program that uses auto or decltype(auto) in a context not explicitly allowed in this subclause is ill-formed.
and we can see it makes a similar case for functions ill-formed in [dcl.spec.auto]p11:
Redeclarations or specializations of a function or function template
with a declared return type that uses a placeholder type shall also
use that placeholder, not a deduced type. Similarly, redeclarations or
specializations of a function or function template with a declared
return type that does not use a placeholder type shall not use a
placeholder. [ Example:auto f();
auto f() return 42; // return type is int
auto f(); // OK
int f(); // error, cannot be overloaded with auto f()
....
So although this could use clarification as currently worded it feels like gcc is correct and this is ill-formed.
Update clang is correct
I asked this question on twitter and the response I received from Richard Smith was as follows:
Not a defect, it's intentional that this restriction applies only to deduced return types and not to variable types. For variables, it's just a convenience shorthand, but return type deduction affects something more fundamental about functions (and especially function templates).
So 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.
Original
Currently [dcl.spec.auto] does not seem to cover this case explictly but it does say in [dcl.spec.auto]p5:
A program that uses auto or decltype(auto) in a context not explicitly allowed in this subclause is ill-formed.
and we can see it makes a similar case for functions ill-formed in [dcl.spec.auto]p11:
Redeclarations or specializations of a function or function template
with a declared return type that uses a placeholder type shall also
use that placeholder, not a deduced type. Similarly, redeclarations or
specializations of a function or function template with a declared
return type that does not use a placeholder type shall not use a
placeholder. [ Example:auto f();
auto f() return 42; // return type is int
auto f(); // OK
int f(); // error, cannot be overloaded with auto f()
....
So although this could use clarification as currently worded it feels like gcc is correct and this is ill-formed.
edited Sep 16 at 8:13
answered Sep 12 at 23:11
Shafik Yaghmour
119k23298494
119k23298494
As already said, I don't see how [dcl.spec.auto]p5 applies here.auto b = a;is a valid use ofauto.
â Rakete1111
Sep 14 at 6:19
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 at 6:54
add a comment |Â
As already said, I don't see how [dcl.spec.auto]p5 applies here.auto b = a;is a valid use ofauto.
â Rakete1111
Sep 14 at 6:19
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 at 6:54
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 at 6:19
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 at 6:19
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 at 6:54
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 at 6:54
add a comment |Â
I believe
[dcl.spec.auto]p5is 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 at 23:32
@ShafikYaghmour: If I think logically,
bis declared as anint. Then, it is defined as anint(asautois deduced asint). 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 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 at 23:40
If this were ill formed then this would mean that defining global variable with
autowould 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 at 0:21
@Galik I recieved a response from Richard Smith on twitter and he seems to agree that clang is correct.
â Shafik Yaghmour
Sep 15 at 14:08