<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 8, 2009, at 10:23 AM, Fariborz Jahanian wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 8, 2009, at 9:46 AM, Douglas Gregor wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 8, 2009, at 7:59 AM, fjahanian wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><br><div><div>On Apr 8, 2009, at 5:02 AM, steve naroff wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><div><div>On Apr 7, 2009, at 11:01 PM, Eli Friedman wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Tue, Apr 7, 2009 at 7:56 PM, Anders Carlsson <<a href="mailto:andersca@mac.com">andersca@mac.com</a>> wrote:<br><blockquote type="cite">Author: andersca<br></blockquote><blockquote type="cite">Date: Tue Apr 7 21:55:55 2009<br></blockquote><blockquote type="cite">New Revision: 68583<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">URL: <a href="http://llvm.org/viewvc/llvm-project?rev=68583&view=rev">http://llvm.org/viewvc/llvm-project?rev=68583&view=rev</a><br></blockquote><blockquote type="cite">Log:<br></blockquote><blockquote type="cite">Don't assume that a block always has a FunctionProtoType. Fixes <a href="rdar://6768379">rdar://6768379</a>.<br></blockquote><br>Maybe we should make "int (^a0)()" and "int (^a0)(void)" equivalent?</div></blockquote><div><br></div>I agree with you. IIRC this is what I originally implemented (in clang). I forget what motivated us to support K&R style as a "convenience" (see excerpt below). Fariborz?</div></blockquote><div><br class="khtml-block-placeholder"></div>In gcc, initially we followed the rules for function pointers for lack of a detailed specification.</div><div>As usage of blocks start getting traction, we tightened the rules as outlined below.</div></div></blockquote><div><br></div><div>Okay, that's this part:</div><div><br></div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 14px/normal Helvetica; "><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; "> A Block that takes no arguments must specify void in the argument list [voidarg.c]. An empty parameter list does not represent, as K&R provide, an unspecified argument list. Note: both gcc and clang support K&R style as a convenience.</div><div><br></div></div></div></blockquote></div></div></blockquote></div></div></div></blockquote></div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>I don't understand what it means for a feature to be a "convenience". Either blocks support can support K&R-style functions without prototypes or they can't. There's no "legacy" code to worry about, here, so it doesn't make any sense to say, "this is wrong, but these compilers support it."</div><div><br></div><div>Personally, I feel that blocks should always require prototypes. It's a new feature without any legacy code to support, and prototypes are the way forward: the C committee seems to favor prototypes, and of course C++ always uses prototypes.</div></div></div></blockquote><div><br class="webkit-block-placeholder"></div>What is the compelling reason not to allow K&R style definition, other than the trend in c standardization?</div></div></blockquote><div><br></div><div>Several reasons:</div><div><br></div><div>1) New language features for C shouldn't go against the trends in the C standardization world. It leads to more fragmentation in the community and undercuts the C committee.<br></div><div><br></div><div>2) K&R-style blocks, like K&R-style function pointers, are not type-safe: it's extremely easy to send the wrong number or wrong kind of arguments to block declared as, e.g., int (^ao)().</div><div><br></div><div>3) Programmers---especially C++ programmers---are very likely to accidentally write int (^a0)() when they mean int (^a0)(void), which means is very easy to accidentally disable type safety. This is *not* something you want for blocks, which are meant to be type-safe abstractions of closures.</div><div><br></div><div>4) If we don't ban K&R-style blocks now, we won't be able to do so in the future because the "legacy code" argument will carry some weight. It's the right thing to do, and it's much harder to do later.</div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Maybe by convenience (I did not write this), it is meant that people who are use to using function pointers</div><div>can adapt blocks more quickly if K&R style is allowed.</div></div></blockquote></div><div><br></div><div>Do we have any examples of this?</div><br><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug<br></div></body></html>