Compiler could elide many more postblit constructor calls

[anonymous]

On Sunday, 30 June 2013 at 08:34:20 UTC, TommiT wrote:
> On Sunday, 30 June 2013 at 08:16:44 UTC, anonymous wrote:
>> On Sunday, 30 June 2013 at 07:27:06 UTC, TommiT wrote:
>>> On Sunday, 30 June 2013 at 02:20:24 UTC, Diggory wrote:
>>>> On Saturday, 29 June 2013 at 17:57:33 UTC, TommiT wrote:
>>>>> On Saturday, 29 June 2013 at 13:47:36 UTC, TommiT wrote:
>>>>>> [..]
>>>>>>
>>>>>> Example:
>>>>>>
>>>>>> ----
>>>>>> struct S
>>>>>> {
>>>>>> int[] values;
>>>>>>
>>>>>> this(this)
>>>>>> {
>>>>>>    values = values.dup;
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> void foo(const S) { }
>>>>>>
>>>>>> void main()
>>>>>> {
>>>>>> const S s;
>>>>>> foo(s); // No need to call postblit
>>>>>> }
>> [...]
>>>>
>>>> Unless the function is pure, this is only possible for 
>>>> immutable parameters otherwise the original variable may be 
>>>> modified while inside the function even if it is passed by 
>>>> const.
>>>
>>> I'm not sure I follow. Are you saying...
>>> 1) the function foo could cast away const and modify s
>>> or
>>> 2) some other thread could modify s while foo is executing
>>
>> 3) foo mutates the data through a mutable global.
>>
>> int[] data = [1, 2, 3];
>> void foo(const S)
>> {
>>    data[0] = 42;
>> }
>> void main()
>> {
>>     const S s = S(data);
>>     foo(s);
>> }
>>
>> Pure functions can't access globals, so they're fine here.
>>
>> (I'm rather ignorant about that whole postblit thing, just 
>> trying to clarify  Diggory's point as I understand it.)
>
> If this is indeed Diggory's point, it's not very pointy 
> (sorry). The compiler should be able to safely omit the 
> postblit on 's' when it passes it to foo (and the possible 
> destructor of foo's argument inside foo when foo exits).

void foo(const S s)
{
     data[0] = 42;
     assert(s.values[0] == 1);
}

With the postblit, the assert holds. Without it, it would fail. 
Isn't that problematic?