https://github.com/dlang/dlang.org/pull/1528 -- Andrei

On 20.12.2016 23:49, Andrei Alexandrescu wrote:
> https://github.com/dlang/dlang.org/pull/1528 -- Andrei

Good, except:

"$(P `pure` functions returning `void` will be always called even if it is strongly `pure`. The implementation must assume the function does something outside the confines of the type system and is therefore not allowed to elide the call, even if it appears to have no possible effect.)"

I think this makes no sense. What is the idea behind this paragraph?

On 12/20/16 7:40 PM, Timon Gehr wrote:
> On 20.12.2016 23:49, Andrei Alexandrescu wrote:
>> https://github.com/dlang/dlang.org/pull/1528 -- Andrei
>
> Good, except:
>
> "$(P `pure` functions returning `void` will be always called even if it
> is strongly `pure`. The implementation must assume the function does
> something outside the confines of the type system and is therefore not
> allowed to elide the call, even if it appears to have no possible effect.)"
>
> I think this makes no sense. What is the idea behind this paragraph?

A function that traces execution via a debug statement, for example. -- Andrei

On Tue, Dec 20, 2016 at 07:58:38PM -0500, Andrei Alexandrescu via Digitalmars-d wrote:
> On 12/20/16 7:40 PM, Timon Gehr wrote:
> > On 20.12.2016 23:49, Andrei Alexandrescu wrote:
> > > https://github.com/dlang/dlang.org/pull/1528 -- Andrei
> > 
> > Good, except:
> > 
> > "$(P `pure` functions returning `void` will be always called even if it is strongly `pure`. The implementation must assume the function does something outside the confines of the type system and is therefore not allowed to elide the call, even if it appears to have no possible effect.)"
> > 
> > I think this makes no sense. What is the idea behind this paragraph?
> 
> A function that traces execution via a debug statement, for example. -- Andrei

Isn't that impure by definition?!  How can tracing execution even be remotely considered pure?

I understand that debug statements are a kind of backdoor to facilitate debugging... but still. I'd expect we wouldn't bend the definition of pure just for the sake of debugging -- that just sounds backwards. If a function has side-effects outside of what's passed as arguments, I can't see any way of justifying it being marked as pure.


T

-- 
They pretend to pay us, and we pretend to work. -- Russian saying

On Tuesday, December 20, 2016 19:58:38 Andrei Alexandrescu via Digitalmars-d wrote:
> On 12/20/16 7:40 PM, Timon Gehr wrote:
> > On 20.12.2016 23:49, Andrei Alexandrescu wrote:
> >> https://github.com/dlang/dlang.org/pull/1528 -- Andrei
> >
> > Good, except:
> >
> > "$(P `pure` functions returning `void` will be always called even if it is strongly `pure`. The implementation must assume the function does something outside the confines of the type system and is therefore not allowed to elide the call, even if it appears to have no possible effect.)"
> >
> > I think this makes no sense. What is the idea behind this paragraph?
>
> A function that traces execution via a debug statement, for example. -- Andrei

Well, ultimately, strongly pure functions that return void are either doing something that works around the type system (e.g. using debug statements to do operations which aren't pure), or they arguably shouldn't even compile, because they can't possibly do anything that has any effect on the program beyond eating up CPU time. So, as far as I can tell, we should either make an exception for them (as the PR currently does) or make them illegal.

- Jonathan M Davis

On Wednesday, 21 December 2016 at 00:58:38 UTC, Andrei Alexandrescu wrote:
> On 12/20/16 7:40 PM, Timon Gehr wrote:
>> On 20.12.2016 23:49, Andrei Alexandrescu wrote:
>>> https://github.com/dlang/dlang.org/pull/1528 -- Andrei
>>
>> Good, except:
>>
>> "$(P `pure` functions returning `void` will be always called even if it
>> is strongly `pure`. The implementation must assume the function does
>> something outside the confines of the type system and is therefore not
>> allowed to elide the call, even if it appears to have no possible effect.)"
>>
>> I think this makes no sense. What is the idea behind this paragraph?
>
> A function that traces execution via a debug statement, for example. -- Andrei

The compiler will have to be changed for this part. Currently it's a warning (or maybe it was an error, can't remember) to call a strongly pure function returning void without doing `cast(void)fun()`.

On 12/20/16 8:10 PM, Meta wrote:
> The compiler will have to be changed for this part. Currently it's a
> warning (or maybe it was an error, can't remember) to call a strongly
> pure function returning void without doing `cast(void)fun()`.

Interesting. As soon as the spec change is merged, we get to file an issue :o). -- Andrei

On 12/20/16 8:02 PM, H. S. Teoh via Digitalmars-d wrote:
> Isn't that impure by definition?!  How can tracing execution even be
> remotely considered pure?

That's why the compiler is required compulsively to call it. -- Andrei

On Tue, Dec 20, 2016 at 08:16:36PM -0500, Andrei Alexandrescu via Digitalmars-d wrote:
> On 12/20/16 8:02 PM, H. S. Teoh via Digitalmars-d wrote:
> > Isn't that impure by definition?!  How can tracing execution even be remotely considered pure?
> 
> That's why the compiler is required compulsively to call it. -- Andrei

I don't follow.

The question was how can a function with side-effects (even given D's relaxed definition of pure, i.e., allowing mutation via arguments) can be considered pure.  What has that got to do with the compiler being required to call it?

I'd say a pure void function should be equivalent to no-op and elidable. If you want to call a function with side-effects from pure code for debugging purposes, call it via the debug statement, e.g.:

	void impureDebugger(...) { ... } // N.B.: NOT pure

	pure void noop() {}

	pure auto pureFunc(A...)(A args) {
		...
		noop();	// may be elided
		...
		debug impureDebugger(1,2,3); // won't be elided
		...
	}

I don't see any good reason why we should bend the definition of pure to allow pure void functions with side effects.


T

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth

On 12/20/16 8:54 PM, H. S. Teoh via Digitalmars-d wrote:
> On Tue, Dec 20, 2016 at 08:16:36PM -0500, Andrei Alexandrescu via Digitalmars-d wrote:
>> On 12/20/16 8:02 PM, H. S. Teoh via Digitalmars-d wrote:
>>> Isn't that impure by definition?!  How can tracing execution even be
>>> remotely considered pure?
>>
>> That's why the compiler is required compulsively to call it. -- Andrei
>
> I don't follow.
>
> The question was how can a function with side-effects (even given D's
> relaxed definition of pure, i.e., allowing mutation via arguments) can
> be considered pure.  What has that got to do with the compiler being
> required to call it?
>
> I'd say a pure void function should be equivalent to no-op and elidable.

If it's elidable, it's as good as a bug in the program. Must be either a compile-time error or a special case. -- Andrei