• bearophile (10/10) Mar 04 2011 It's now OK to create a new array in a nothrow function, but it seems du...
• Simen kjaeraas (5/14) Mar 04 2011 It's probably correct that _adDupT is not nothrow. It is also wrong
• bearophile (9/11) Mar 04 2011 I was about to write a bug report regarding allowing dupping in nothrow ...
• Simen kjaeraas (5/16) Mar 04 2011 Not sure it's doing the exact same thing, but in essence, it is. It's a
• Steven Schveighoffer (14/32) Mar 07 2011 There are some assumptions that we have to make for memory allocation. ...

bearophile <bearophileHUGS lycos.com> writes:

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

"Simen kjaeraas" <simen.kjaras gmail.com> writes:

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

bearophile <bearophileHUGS lycos.com> writes:

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

"Simen kjaeraas" <simen.kjaras gmail.com> writes:

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

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

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