__has_side_effects

[Jonathan M Davis]

On Sunday, April 01, 2018 06:23:40 Andrei Alexandrescu via Digitalmars-d 
wrote:
> On 4/1/18 2:22 AM, Uknown wrote:
> > On Sunday, 1 April 2018 at 05:27:38 UTC, Uknown wrote:
> >> [...]
> >>
> >> I knew I was missing something. Fixed it, thanks
> >>
> >> https://run.dlang.io/is/tZeZrP
> >
> > Sorry for the spam, but I also managed to miss `immutable`, `const` and
> > when T has mutable indirections
> >
> > Final version that I'm sure covers all the cases:
> >
> > https://run.dlang.io/is/kGoU4X
>
> That's a great initiative, and a worthy trait for the stdlib. I think
> you'd have an easier time if you reasoned from the other end. A function
> is strongly pure if all of the following are true:
>
> * Each parameter:
>    - is immutable, OR
>    - can be converted automatically to immutable (i.e. has no mutable
> indirections) AND is passed by value
> * The return type:
>    - is immutable, OR
>    - can be converted automatically to immutable
>
> (We don't want to give const this much power yet for other reasons.)

In principle, a function which has const parameters could be treated as
strongly pure if it's given immutable arguments, but I don't believe that
the language does that, and in that case, you couldn't just test a function
to see if it was strongly pure, since in some cases, it would depend on the
arguments. So, to test for strong purity, you'd need both the function and
the arguments, meaning that it wouldn't so much be the case that a function
was strongly pure as a function call was strongly pure. Such a change to
strong purity would increase the number of optimizations that could be based
on pure, but I don't know that it would be worth it, especially since it
would then be much harder to have a trait like this, and functions are so
rarely called with the same arguments in the same expression or statement
that I'm not sure that such a change would really add much in the way of
optimization opportunities.

- Jonathan M Davis