Small Buffer Optimization for string and friends

[Nick Sabalausky]

"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:jlut8k$j4o$1 at digitalmars.com...
>
> I agree. So we have the counterarguments:
>
> 1. Lowering would treat array primitives as sheer D code, subject to 
> refusal of inlining. That means worse performance.
>

So in other words, we need the @forceinline that some people have strongly 
requested? Make it work even without -inline, and then add -noinline for any 
rare cases where someone might need to forcefully disable @forceinline. 
Shouldn't that take care of it?

> 2. Unless the compiler takes special measures, source-level debuggers will 
> trace through core, uninteresting code for array operations.
>

Would @forceinline fix this?

> 3. There are patterns that attempt to optimize by e.g. using .ptr, but end 
> up pessimizing code because they trigger multiple memory allocations.

Someone's suggestion of just making .ptr null instead of doing implicit 
allocations was an interesting idea.