<div class="gmail_quote">On 9 April 2012 17:55, 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="im">On 4/9/12 4:21 AM, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
After thinking on it a bit, I'm becoming a little worried about this<br>
move for 2 rarely considered reasons:<br>
Using lowering to a template, debug(/unoptimised) performance will<br>
probably get a lot slower, which is really annoying. And<br>
debugging/stepping might become considerably more annoying too, if every<br>
time I press F11 (step in) over a function call that happens to receive<br>
an arg from an array, the debugger then steps into the array templates<br>
index operator... We'd be no better off than with STL, unless the<br>
language has clever ways of hiding this magic from the debugger too, and<br>
optimising/inlining the index even in debug builds...? But this is the<br>
built-in array, and not a library we can optionally not use.<br>
</blockquote>
<br></div>
I agree. So we have the counterarguments:<br>
<br>
1. Lowering would treat array primitives as sheer D code, subject to refusal of inlining. That means worse performance.<br>
<br>
2. Unless the compiler takes special measures, source-level debuggers will trace through core, uninteresting code for array operations.<br>
<br>
3. There are patterns that attempt to optimize by e.g. using .ptr, but end up pessimizing code because they trigger multiple memory allocations.</blockquote><div><br></div><div>Indeed. I don't think the small array optimisation would benefit us in any way that could even come close to balancing the loss. I don't think it would benefit us much at all regardless, since we've already proven the need for a string class anyway, and we can make such small-string optimisations already.</div>
<div>I am very wary of removing a fundamental language primitive, that is, the basic ability to express an array with absolutely no frills.</div><div><br></div><div>This idea only really benefits utf-8 strings, so why not just make a real d-string class in phobos and be done with it? People complain about UTF issues with raw strings, and this is what you intend to do anyway to implement the optimisation.</div>
<div>d-string could perhaps be made to appear as a first-class language feature via the 'string' keyword, and lower to the library in the way you describe. Just don't blanket this across all arrays in general.</div>
</div>