<div class="gmail_quote">On 27 August 2012 07:52, Walter Bright <span dir="ltr"><<a href="mailto:newshound2@digitalmars.com" target="_blank">newshound2@digitalmars.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 8/26/2012 9:25 PM, Chris Cain wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Monday, 27 August 2012 at 04:01:10 UTC, Walter Bright wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What happens with the name mangling? What about overloading? template type<br>
deduction? type specialization? type equivalence? type covariance?<br>
</blockquote>
<br>
Name mangling: Without knowing enough about compiler making, I'm not sure why it<br>
matters. I couldn't answer, sorry.<br>
</blockquote>
<br></div>
The mangled names have a 1:1 correspondence with types. A mangled name can, for example, be reversed into a type.<br>
<br>
If default args form part of the type, then they'll have to be mangled in, too. This causes a rather long list of substantial problems.<br>
</blockquote></div><br><div>This sounds like an implementation detail/dmd quirk is defining the language spec...</div><div>I generally agree with the usage proposal above, it should be metadata that doesn't affect type equivalence (although I'd probably expect is(f1 == f2def) should be true rather than false).</div>
<div>If that info needs to be mangled into the name to reproduce the type later, fine, is that a problem? Perhaps stick it at the end of the mangled name in a new metadata suffix that is truncated prior to any comparisons for equality?</div>
<div><br></div><div>This actually rather relates to the attribute/annotation proposals/conversations we were having some time back. If this is addressed, then it may enable attributes too.</div>