Talk:Most vexing parse

NPOV
"extremely counterintuitive" ... NPOV anyone? I personally think it is the most appropriate way. A function returning T named f, taking nothing? T f;. no matter what context. —Preceding unsigned comment added by 213.61.9.74 (talk) 12:12, 24 January 2011 (UTC)
 * Agreed. I made an attempt at rewriting the lede.  (talk) 13:07, 24 January 2011 (UTC)

Explanation of Name
Where does the term "most vexing parse" come from? How exactly is it defined? A lot of space is currently devoted to examples, but there's not a lot of description of the actual definition of the concept. -- 140.142.20.101 (talk) 01:12, 6 March 2012 (UTC)

+1 to the above 2620:0:1042:0:D267:E5FF:FEEC:80D2 (talk) 18:30, 26 November 2013 (UTC)

Bad Example?
Regarding the "TimeKeeper time_keeper(Timer)" example: A) TimeKeeper time_keeper is also MVP, so why complicate things? B) Programmers would write "Timer" as void(*Timer), and it's surprising that it should be permitted to work the other way. In any case, without at least "void Timer" on what systems does this compile? Not saying it's wrong, just a needlessly complicated/dubious example. --184.21.224.130 (talk) 19:53, 9 July 2016 (UTC) EDITED: I see, how strange; Timer is the return type with this syntax??? Why is this not banned by default. So is this specific example MVP? Because "TimeKeeper time_keeper" is also vexing, in pretty much the same way. The most vexing thing about this is that "Timer" is even a legal construction inside of the function signature (it's not permitted anywhere else.) --184.21.224.130 (talk) 20:05, 9 July 2016 (UTC)

is, not. Magic sergeant (talk) 04:12, 8 June 2018 (UTC)

A function type (like ) as a parameter type automatically decays to a pointer-to-function type (in this case,  ), analogous to   decaying to. Magic sergeant (talk) 04:18, 8 June 2018 (UTC)

It is not allowed anywhere else because such decaying process does not occur anywhere else Magic sergeant (talk) 04:23, 8 June 2018 (UTC)