I'd just like to toss one in there. .dup and .idup for slices and associative arrays. I've seen a few cases where these functions are not nothrow when they could be. (Because OutOfMemoryError is an Error, not an Exception.)

On Thursday, 20 March 2014 at 12:51:35 UTC, w0rp wrote:
> I'd just like to toss one in there. .dup and .idup for slices and associative arrays. I've seen a few cases where these functions are not nothrow when they could be. (Because OutOfMemoryError is an Error, not an Exception.)

The reasons it's not nothrow is because because dup causes postblit, and postblit could throw.

Of course, by that same token, postblit could be unsafe and impure. It's terribly inconsistent.

Which is another big problem of druntime: Mostly everything in it is done at run-time using typeid, so there is no static inference.

On Tuesday, 18 March 2014 at 23:56:15 UTC, Steven Schveighoffer wrote:
> On Tue, 18 Mar 2014 19:48:45 -0400, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> On 3/18/2014 4:20 PM, Steven Schveighoffer wrote:
>>> In a recent (well, recently pulled anyway) pull request that Monarch Dodra
>>> brought up, we debated what should be considered nothrow in the depths of druntime.
>>
>> There's a lot of low hanging nothrow fruit in druntime that doesn't need analysis, it just needs to get done:
>>
>> https://d.puremagic.com/issues/show_bug.cgi?id=12389
>
> Can we mark _d_monitorenter and _d_monitorexit nothrow and have the compiler see that when using synchronized? This was the hurdle we couldn't overcome in the referenced pull request.
>
> Should those be marked nothrow? What about pure and @safe?

I'd be inclined to say yes.  Although monitors use lazy initialization, I think the failure to initialize a monitor should probably be considered an Error.

On 3/18/2014 5:49 PM, Walter Bright wrote:
> On 3/18/2014 4:56 PM, Steven Schveighoffer wrote:
>> Can we mark _d_monitorenter and _d_monitorexit nothrow and have the compiler see
>> that when using synchronized? This was the hurdle we couldn't overcome in the
>> referenced pull request.
>>
>> Should those be marked nothrow? What about pure and @safe?
>
> Good question. I don't have an answer at the moment.
>

I'm pretty sure they can't be pure. After all, monitors affect global state, can result in deadlocks, etc.

On Thu, 20 Mar 2014 17:32:01 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/18/2014 5:49 PM, Walter Bright wrote:
>> On 3/18/2014 4:56 PM, Steven Schveighoffer wrote:
>>> Can we mark _d_monitorenter and _d_monitorexit nothrow and have the compiler see
>>> that when using synchronized? This was the hurdle we couldn't overcome in the
>>> referenced pull request.
>>>
>>> Should those be marked nothrow? What about pure and @safe?
>>
>> Good question. I don't have an answer at the moment.
>>
>
> I'm pretty sure they can't be pure. After all, monitors affect global state, can result in deadlocks, etc.

How do they affect global state?

Resulting in deadlocks does not make them impure. This is also a pure function:

pure int foo()
{
   while(1) {}
   return 0;
}

Pure doesn't mean "bug free".

-Steve

Steven Schveighoffer:

> This is also a pure function:
>
> pure int foo()
> {
>    while(1) {}
>    return 0;
> }
>
> Pure doesn't mean "bug free".

Thankfully the D compiler catches the bug :-)

test.d(3,4): Warning: statement is not reachable

Bye,
bearophile

On Thu, 20 Mar 2014 21:44:38 -0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Steven Schveighoffer:
>
>> This is also a pure function:
>>
>> pure int foo()
>> {
>>    while(1) {}
>>    return 0;
>> }
>>
>> Pure doesn't mean "bug free".
>
> Thankfully the D compiler catches the bug :-)
>
> test.d(3,4): Warning: statement is not reachable

I can make it not catch that error, but that is not the bug. The bug is that it never returns, effectively deadlocking. The sample is intentionally short to demonstrate my point, I (obviously) didn't try to compile it.

-Steve

On 3/20/2014 6:40 PM, Steven Schveighoffer wrote:
> How do they affect global state?

Mutexes implicitly share state. It's the reason they exist. They can't be pure, because pure functions don't share state.

On Friday, 21 March 2014 at 02:00:11 UTC, Walter Bright wrote:
> On 3/20/2014 6:40 PM, Steven Schveighoffer wrote:
>> How do they affect global state?
>
> Mutexes implicitly share state. It's the reason they exist. They can't be pure, because pure functions don't share state.

If you got that road, you can't allow memory allocators to be
used in pure code. That isn't a good argument.

On Thu, 20 Mar 2014 22:00:15 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/20/2014 6:40 PM, Steven Schveighoffer wrote:
>> How do they affect global state?
>
> Mutexes implicitly share state. It's the reason they exist. They can't be pure, because pure functions don't share state.

I view it differently. I feel like locking and unlocking a mutex is pure. After calling lock, the same thing *always* happens. After unlocking, the same thing *always* happens. It's a weird thing -- when you lock a mutex, you own it after it's locked. It's no longer shared. It can be thought of as pulling memory out of the heap to temporarily own, and then putting it back, just like memory allocation (which is considered pure).

This is quite different from actual global state, which is accessed via globals.

trylock I don't think should be pure. I'm not sure about read/write locks.

-Steve