It's now OK to create a new array in a nothrow function, but it seems dup is not allowed:


nothrow void foo(int[] a) {
    a.dup;
}
void main() {}


Errors with dmd 2.052, is this correct?
test.d(2): Error: _adDupT is not nothrow
test.d(1): Error: function test.foo 'foo' is nothrow yet may throw

Bye,
bearophile

bearophile <bearophileHUGS@lycos.com> wrote:

> It's now OK to create a new array in a nothrow function, but it seems dup is not allowed:
>
>
> nothrow void foo(int[] a) {
>     a.dup;
> }
> void main() {}
>
>
> Errors with dmd 2.052, is this correct?
> test.d(2): Error: _adDupT is not nothrow
> test.d(1): Error: function test.foo 'foo' is nothrow yet may throw

It's probably correct that _adDupT is not nothrow. It is also wrong
that it shouldn't be.

-- 
Simen

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() {}


Bye,
bearophile

bearophile <bearophileHUGS@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.

-- 
Simen

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

> bearophile <bearophileHUGS@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