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

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
11
down vote

favorite
1













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?)










share|improve this question















marked as duplicate by M.M c++
Users with the  c++ badge can single-handedly close c++ questions as duplicates and reopen them as needed.

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]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











  • 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










  • @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














up vote
11
down vote

favorite
1













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?)










share|improve this question















marked as duplicate by M.M c++
Users with the  c++ badge can single-handedly close c++ questions as duplicates and reopen them as needed.

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]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











  • 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










  • @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












up vote
11
down vote

favorite
1









up vote
11
down vote

favorite
1






1






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?)










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 c++
Users with the  c++ badge can single-handedly close c++ questions as duplicates and reopen them as needed.

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 c++
Users with the  c++ badge can single-handedly close c++ questions as duplicates and reopen them as needed.

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]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











  • 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










  • @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











  • @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











  • 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















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












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.)






share|improve this answer


















  • 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

















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.






share|improve this answer






















  • 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


















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.)






share|improve this answer


















  • 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














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.)






share|improve this answer


















  • 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












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.)






share|improve this answer














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.)







share|improve this answer














share|improve this answer



share|improve this answer








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












  • 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












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.






share|improve this answer






















  • 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















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.






share|improve this answer






















  • 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













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.






share|improve this answer














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.







share|improve this answer














share|improve this answer



share|improve this answer








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 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

















  • 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
















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



Popular posts from this blog

Peggy Mitchell

Palaiologos

The Forum (Inglewood, California)