Dupping in a nothrow function?

[Steven Schveighoffer]

On Fri, 04 Mar 2011 17:55:15 -0500, Simen kjaeraas  
<simen.kjaras at gmail.com> wrote:

> bearophile <bearophileHUGS at lycos.com> wrote:
>
>> Simen kjaeraas:
>>
>>> It's probably correct that _adDupT is not nothrow. It is also wrong
>>> that it shouldn't be.
>>
>> I was about to write a bug report regarding allowing dupping in nothrow  
>> functions, because this is now allowed, and I think this is the same  
>> thing as doing a dup:
>>
>>
>> nothrow void foo(int[] a) {
>>     auto b = new int[a.length];
>>     b[] = a[];
>> }
>> void main() {}
>
> Not sure it's doing the exact same thing, but in essence, it is. It's a
> bug, for sure.

There are some assumptions that we have to make for memory allocation.   
For example, memory allocation is pure even though it alters global state,  
and returns different values.  Memory allocation should be considered  
nothrow, even though it could throw an out of memory error.  If we don't  
make these assumptions, the result is we have an absurdly limited language  
for the sake of some very obscure or rare cases.

I think duping should be allowed in a nothrow function, no question.

However, one thing to consider, the runtime currently does not correctly  
obey postblit functions when duping or reallocating arrays.  Once those  
are properly obeyed, if those are not marked nothrow, we need to disallow  
the dup.

-Steve