Function attribute best practices

[Steven Schveighoffer]

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.

-Steve