On 18/07/2021 12:56 AM, Dennis wrote:
> I don't know whether the spec or code is correct.

Unless otherwise specified, the code is authoritative.

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.

On 17.07.21 15:56, ag0aep6g wrote:
> 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've dug a bit deeper, and apparently I'm to blame for confusing things. In issue 15862 [1], I stated that functions with mutable indirections in the return type cannot be strongly pure. That's wrong, but it seems to have found its way into DMD.

The core of issue 15862 is true: Two calls to `array` cannot be merged into one. But that doesn't make it weakly pure. Mutability in the return type is distinct from weak/strong purity.

These are all true:

* `array` is "strongly pure".
* `array` is a "pure factory function".
* The result of one call to `array` cannot be reused for another, identical call.


[1] https://issues.dlang.org/show_bug.cgi?id=15862.