<br><br><div class="gmail_quote">On 6 January 2012 23:23, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:SeeWebsiteForEmail@erdani.org">SeeWebsiteForEmail@erdani.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 1/6/12 1:11 PM, Walter Bright wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 1/6/2012 10:25 AM, Brad Roberts wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How is making __v128 a builtin type better than defining it as:<br>
<br>
align(16) struct __v128<br>
{<br>
ubyte[16] data;<br>
}<br>
</blockquote>
<br>
Then the back end knows it should be mapped onto the XMM registers<br>
rather than the usual arithmetic set.<br>
</blockquote>
<br></div></div>
If it's possible, then it would be great to express the new constructs within the existing language (optionally by leaving it to the implementation to strengthen guarantees of certain constructs).<br></blockquote><div>
<br></div><div>Now you're at odds with Walter's new take on it.. He seems to have changed his mind and decided library implementation of the complex/strict types is a bad idea now..?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I very warmly recommend avoiding defining things in the language and compiler wherever the same is possible within a library (however non-portable). Confining features to the language/compiler drastically reduces the number of people that can work on them.</blockquote>
<div><br></div><div>Aye, and my proposal requests only the minimum support required from the language, allowing libraries to do the rest.</div><div>For some reason Walter seems to have done a bit of a 180 in the last few hours ;)</div>
</div>