<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 12, 2008, at 6:13 PM, Argiris Kirtzidis wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>steve naroff wrote:<br><blockquote type="cite">All good points...<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Sometimes it's useful to consult the spec to help weigh various design points.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">That said, C99 6.7.2.3p3 says...<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">All declarations of structure, union, or enumerated types that have the same scope and use the same tag declare the same type. The type is incomplete109) until the closing brace of the list deļ¬ning the content, and complete thereafter. <br></blockquote><blockquote type="cite">Since both x and y have the same type, I don't see any compelling reason to alter the type system.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">struct S{} x;<br></blockquote><blockquote type="cite">struct S y;<br></blockquote><br>C99 6.7.7p7 says:<br>All three of the following declarations of the signal function specify exactly the same type<br><br>typedef void fv(int), (*pfv)(int);<br>void (*signal(int, void (*)(int)))(int);<br>fv *signal(int, fv *);<br>pfv signal(int, pfv);<br><br>And we don't actually use "exactly the same type", we use TypedefType to capture more syntactic information.</div></blockquote><div><br></div>Typedef's are an explicit language feature for introducing <i>user-defined</i> synonyms.</div><div><br></div><div>The only reason for representing TypedefType explicitly in the type system is to output <i>user-defined</i> names in diagnostics. In fact, I wish we didn't have to deal with them explicitly in the type system. When I started writing Sema, I can't tell you how many bugs resulted in accidentally operating on the non-canonical type. Nevertheless, the pain was worth the gain (for typedefs). I'm not convinced adding more pain for the case above is worth it. Nevertheless, I see the point you are making a bit more clearly...</div><div><br></div><div><blockquote type="cite"><div><br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">From my perspective, we need to have a compelling reason to fold this into the type system.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">If not, I think the DeclGroup solution will work fine (and appears simpler).<br></blockquote><br>See here:<br><a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-September/002807.html">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-September/002807.html</a><br>about why I think folding it in the type is simpler.<br><br></div></blockquote><div><br></div>This helps me understand the problems you are considering, however I still don't think folding it into the type system is the right thing. Adorning a Decl with more type-specifier info is fine though.</div><div><br></div><div>snaroff</div><div><br><blockquote type="cite"><div>-Argiris<br></div></blockquote></div><br></body></html>