Walter, are the changes that you've been making to pure, nothrow, and @safe in dmd essentially done for the moment? Or are there still more to come? They've reaked some level of havoc with Phobos (for better or worse), and so assuming that all of the changes that you've made are valid, some changes are going to need to be made to Phobos so that the unit tests will compile again, but I don't see much point in trying to sort any of that out if you're still in the middle of making big changes.

Regardless, I'm particularly stumped by the errors in std.concurrency. It seems like the combination of purity and nothrow inference and making the compiler complain about calling pure nothrow functions without using the result is breaking it (certainly, I don't see any pure nothrow functions in there anywhere, so I have no idea how else it could be complaining about pure nothrow functions having no effect). So, I don't know if that's a compiler issue or an issue with std.concurrency. But I don't want to try and fix anything yet if you're still making big changes.

- Jonathan M Davis

On 6/26/2011 8:09 PM, Jonathan M Davis wrote:
> Walter, are the changes that you've been making to pure, nothrow, and @safe in dmd essentially done for the moment? Or are there still more to come? They've reaked some level of havoc with Phobos (for better or worse), and so assuming that all of the changes that you've made are valid, some changes are going to need to be made to Phobos so that the unit tests will compile again, but I don't see much point in trying to sort any of that out if you're still in the middle of making big changes.
>
> Regardless, I'm particularly stumped by the errors in std.concurrency. It seems like the combination of purity and nothrow inference and making the compiler complain about calling pure nothrow functions without using the result is breaking it (certainly, I don't see any pure nothrow functions in there anywhere, so I have no idea how else it could be complaining about pure nothrow functions having no effect). So, I don't know if that's a compiler issue or an issue with std.concurrency. But I don't want to try and fix anything yet if you're still making big changes.
>

I'm going to just back out the warning about pure functions with no effect.

On 2011-06-26 20:34, Walter Bright wrote:
> On 6/26/2011 8:09 PM, Jonathan M Davis wrote:
> > Walter, are the changes that you've been making to pure, nothrow, and @safe in dmd essentially done for the moment? Or are there still more to come? They've reaked some level of havoc with Phobos (for better or worse), and so assuming that all of the changes that you've made are valid, some changes are going to need to be made to Phobos so that the unit tests will compile again, but I don't see much point in trying to sort any of that out if you're still in the middle of making big changes.
> > 
> > Regardless, I'm particularly stumped by the errors in std.concurrency. It seems like the combination of purity and nothrow inference and making the compiler complain about calling pure nothrow functions without using the result is breaking it (certainly, I don't see any pure nothrow functions in there anywhere, so I have no idea how else it could be complaining about pure nothrow functions having no effect). So, I don't know if that's a compiler issue or an issue with std.concurrency. But I don't want to try and fix anything yet if you're still making big changes.
> 
> I'm going to just back out the warning about pure functions with no effect.

Okay. Fine with me. It would be kind of nice to know what on earth is going on with std.concurrency though, since in theory, warning about pure functions with no effect would be a good thing. But I don't even know how it has a pure function with no effect to complain about.

- Jonathan M Davis

On 6/26/11 10:34 PM, Walter Bright wrote:
> I'm going to just back out the warning about pure functions with no effect.

Why? I think that would be a mistake. Roll in any way you wish (after fixing bugs and all), but do roll it it. There's absolutely never a good reason to call a pure function and ignore its result, unless you just want to keep the CPU warm.

Andrei

On 27 June 2011 05:50, Andrei Alexandrescu <andrei at erdani.com> wrote:
> On 6/26/11 10:34 PM, Walter Bright wrote:
>>
>> I'm going to just back out the warning about pure functions with no effect.
>
> Why? I think that would be a mistake. Roll in any way you wish (after fixing bugs and all), but do roll it it. There's absolutely never a good reason to call a pure function and ignore its result, unless you just want to keep the CPU warm.

Yes there is. In cases where you want to pass an empty delegate literal to a function which requires a delegate.

On 6/26/2011 8:50 PM, Andrei Alexandrescu wrote:
> On 6/26/11 10:34 PM, Walter Bright wrote:
>> I'm going to just back out the warning about pure functions with no effect.
>
> Why? I think that would be a mistake. Roll in any way you wish (after fixing bugs and all), but do roll it it. There's absolutely never a good reason to call a pure function and ignore its result, unless you just want to keep the CPU warm.
>

Because with pure & nothrow inference, it breaks a lot of code, for example code like this:

void foo(int i)
{
     assert(i == 3);
}

On 6/26/11 10:56 PM, Don Clugston wrote:
> On 27 June 2011 05:50, Andrei Alexandrescu<andrei at erdani.com>  wrote:
>> On 6/26/11 10:34 PM, Walter Bright wrote:
>>>
>>> I'm going to just back out the warning about pure functions with no effect.
>>
>> Why? I think that would be a mistake. Roll in any way you wish (after fixing bugs and all), but do roll it it. There's absolutely never a good reason to call a pure function and ignore its result, unless you just want to keep the CPU warm.
>
> Yes there is. In cases where you want to pass an empty delegate literal to a function which requires a delegate.

Interesting. I wonder whether empty functions should be handled as a special case or are part of a pattern.

Andrei

On 6/26/11 11:00 PM, Walter Bright wrote:
> On 6/26/2011 8:50 PM, Andrei Alexandrescu wrote:
>> On 6/26/11 10:34 PM, Walter Bright wrote:
>>> I'm going to just back out the warning about pure functions with no effect.
>>
>> Why? I think that would be a mistake. Roll in any way you wish (after fixing bugs and all), but do roll it it. There's absolutely never a good reason to call a pure function and ignore its result, unless you just want to keep the CPU warm.
>>
>
> Because with pure & nothrow inference, it breaks a lot of code, for example code like this:
>
> void foo(int i)
> {
> assert(i == 3);
> }

Hmmm... in this case, the function may terminate the program. Probably in such a case there should be no warning anyway - it does have an effect.

Andrei

On 6/26/2011 9:16 PM, Andrei Alexandrescu wrote:
>
> Interesting. I wonder whether empty functions should be handled as a special case or are part of a pattern.
>
>

One thing I don't want to do is add another attribute:

     @impure void foo(int i) { ... }

On 2011-06-26 21:20, Andrei Alexandrescu wrote:
> On 6/26/11 11:00 PM, Walter Bright wrote:
> > On 6/26/2011 8:50 PM, Andrei Alexandrescu wrote:
> >> On 6/26/11 10:34 PM, Walter Bright wrote:
> >>> I'm going to just back out the warning about pure functions with no effect.
> >> 
> >> Why? I think that would be a mistake. Roll in any way you wish (after fixing bugs and all), but do roll it it. There's absolutely never a good reason to call a pure function and ignore its result, unless you just want to keep the CPU warm.
> > 
> > Because with pure & nothrow inference, it breaks a lot of code, for example code like this:
> > 
> > void foo(int i)
> > {
> > assert(i == 3);
> > }
> 
> Hmmm... in this case, the function may terminate the program. Probably
> in such a case there should be no warning anyway - it does have an effect.

Except that any case where you need a delegate which specifically does nothing (as Don suggested), it probably wouldn't have an assert, since it's not intended to fail - just do nothing. And, of course, this particular function can only fail if assertions are turned on, which makes it a bit funny. Certainly, it would suck if this function weren't complained about when the assertion was compiled in but failed to compile with -release.

Overall, it seems like warning about functions with no effect would make a lot of sense, but it is looking like there are valid cases where you'd want to have functions with no effect beyond being called, which makes warning about any of them problematic. So, I don't know if we can have warnings about any of them or not. Certainly, the situation with this is far more complicated than it first appears.

- Jonathan M Davis