On 9/12/22 1:08 PM, Ali Çehreli wrote:
On 9/12/22 09:48, H. S. Teoh wrote:

 >> @nogc nothrow pure @safe
 >> unittest
 >> {
 >>      // ...
 >> }
 >> No, it isn't because unless my unittest code is impure, I can't catch
 >> my incorrect 'pure' etc. on my member functions.
 > [...]
 > Sure you can.  The `pure unittest` code obviously must itself be pure
 > (otherwise it wouldn't compile). If Foo introduces impure behaviour,
 > then the unittest, being pure, wouldn't be allowed to call Foo's impure
 > methods, which is what we want.  What's the problem?

There was a problem until you and others put me straigth. :)

What I meant was

- if I put 'pure' etc. on my templatized code,

- and then tested with a 'pure' unittest,

I wouldn't know that the gratuitous use of my 'pure' on the member function was wrong. I would be fooling myself thinking that I smartly wrote a 'pure' member function and a 'pure' unittest and all worked. Wrong idea! :)

So you are thinking about this the wrong way I believe.

When you put `pure` on a template function, you are saying "only instantiations where this function can be pure are allowed". Essentially, that's *you* telling your *user* "this must be pure!".

If your intent is to *enforce* pure functions only, then that's what you do. If your intent instead is to ensure that given proper parameters, the function will be pure, then the answer is to unittest.

I will say, sometimes this gets really annoying. Like if the unittest fails, you get very little information about *why* it's not working.

i.e. you expect the inference to be pure, but it's not. All you get is "impure unittest can't call impure function foo(...)". Figuring out the misinference cause is a chore today. I wish it would be easier.


Reply via email to