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
