Major performance problem with std.array.front()

[Steven Schveighoffer]

On Mon, 10 Mar 2014 22:56:22 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 3/10/14, 7:07 PM, Steven Schveighoffer wrote:
>> On Mon, 10 Mar 2014 19:59:07 -0400, Walter Bright
>> <newshound2 at digitalmars.com> wrote:
>>
>>> On 3/10/2014 6:47 AM, Dicebot wrote:
>>>> (array literals that allocate, I will never forgive that).
>>>
>>> It was done that way simply to get it up and running quickly. Having
>>> them not allocate is an optimization, it doesn't change the nature.
>>
>> I think you forget about this:
>>
>> foo(int v, int w)
>> {
>>     auto x = [v, w];
>> }
>>
>> Which cannot pre-allocate.
>
> It actually can, seeing as x is a dead assignment :o).

Actually, it can't do anything, seeing as it's invalid code ;)

>> That said, I would not mind if this code broke and you had to use
>> array(v, w) instead, for the sake of avoiding unnecessary allocations.
>
> Fixing that:
>
> int[] foo(int v, int w) { return [v, w]; }
>
> This one would allocate. But analyses of varying complexity may  
> eliminate a variety of allocation patterns.

I think you are missing what I'm saying, I don't want the allocation  
eliminated, but if we eliminate some allocations with [] and not others,  
it will be confusing. The path I'd always hoped we would go in was to make  
all array literals immutable, and make allocation of mutable arrays on the  
heap explicit.

Adding eliding of some allocations for optimization is good, but I (and I  
think possibly Dicebot) think all array literals should not allocate.

-Steve