On 17.07.21 14:56, Dennis wrote:
On Saturday, 17 July 2021 at 12:05:44 UTC, ag0aep6g wrote:
Hm, as far as I understand, "strongly pure" doesn't require
`immutable` parameters. `const` should be enough. The spec says: "A
strongly pure function has no parameters with mutable indirections" [1].
I just took the description from the source code:
```D
enum PURE : ubyte
{
impure = 0, // not pure at all
fwdref = 1, // it's pure, but not known which level yet
weak = 2, // no mutable globals are read or written
const_ = 3, // parameters are values or const
strong = 4, // parameters are values or immutable
}
```
That looks off to me. Unless DMD has some secret knowledge about a
shortcoming in the established definition of "strongly pure", I think
those enum values are badly named.
At a glance, the only meaningful use of `PURE.strong` seems to be in
dcast.d, introduced by the PR you linked. Changing that to `PURE.const_`
doesn't break any tests for me. So I'm inclined to believe that
`PURE.strong` is nonsense, and that `PURE.const_` already means
"strongly pure".
However, changing that instance doesn't fix the issue. Apparently, DMD
doesn't even recognize
int[] array(const int[] input) pure { ... }
as `PURE.const_`.
I don't know whether the spec or code is correct.
When it comes to purity, another piece in the puzzle is David
Nadlinger's article:
https://klickverbot.at/blog/2012/05/purity-in-d/
There, a function with a `const int[]` parameter is described as
"strongly pure".
As far as I can remember, when DMD and that article disagreed in the
past, DMD was wrong.
[...]
Yup, [remember
this](https://github.com/dlang/dmd/pull/8035#discussion_r174771516)?
Hehe, I knew I had complained about it before.
It's doubly bad: (1) We're missing out on bug fixes, because they're
hidden behind `-preview=dip1000` for no reason. (2) When
`-preview=dip1000` ever becomes the default, code will break that
doesn't even use the features of DIP 1000.
