In Pure Factory Functions, it says what conversions are enabled for the result of a strongly pure function because the result is unique.

For one of my last PRs, I went through all possible combination of qualifiers and all pairs of these types. While I found no problematic conversion that was allowed, I did find conversions that should be allowed, but DMD rejects them. All of those involve inout; in particular, whatever of mutable, const, and immutable you replace inout on both sides with (if at both sides), the conversion is allowed for a pure factory function, but not for inout. As far as I understand inout, this makes no sense and they should be allowed by D’s type system.

Can someone take a look at the list and tell me if I’m mistaken with some (or all) of them?

Here is the code, for those interested.

On 2/10/23 7:53 AM, Kagamin wrote:

It can be weakly pure. The docs are wrong.

i.e. this works:

pure int *foo(const int *p)
{
   return new int(5);
}

void main()
{
   int x;
   immutable int * bar = foo(&x);
}

-Steve

On Friday, 10 February 2023 at 14:00:20 UTC, Steven Schveighoffer wrote:

pure int *foo(const int *p)
{
   return new int(5);
}

void main()
{
   int x;
   immutable int * bar = foo(&x);
}

That function "has no parameters with mutable indirections". So it's strongly pure, not weakly pure.

I'd guess that inout counts like const with regards to weak/strong purity. So a pure function with inout parameters is also strongly pure.

On Friday, 10 February 2023 at 14:00:20 UTC, Steven Schveighoffer wrote:

Looks like the check is deeper.
This doesn't work:

struct A
{
	const int[] a;
}
pure A a(const int[] b)
{
	return A(b);
}
void e()
{
	int[] b;
	immutable A c=a(b);
}

On Friday, 10 February 2023 at 15:23:04 UTC, Kagamin wrote:

struct A
{
	const int[] a;
}
pure A a(const int[] b)
{
	return A(b);
}
void e()
{
	int[] b;
	immutable A c=a(b);
}

The spec currently says that the result of a pure factory function "has mutable indirections". It should probably say that the result "has only mutable indirections".

Then it would be clear that a is not a pure factory function.

On 2/10/23 9:37 AM, ag0aep6g wrote:

pure int *foo(const int *p)
{
   return new int(5);
}

void main()
{
   int x;
   immutable int * bar = foo(&x);
}

I thought strong purity had to do with call elision/memoization. Clearly, calling with a const pointer can't be elided or memoized if passed a mutable.

So the spec is consistent I guess, I just misunderstood what constituted "strong" purity.

However, the Optimization section does state:

   An implementation may assume that a strongly pure function that returns a result without mutable indirections will have the same effect for all invocations with equivalent arguments. It is allowed to memoize the result of the function under the assumption that equivalent parameters always produce equivalent results."

I feel like this is not a sound assumption if the parameter is const, and the argument is mutable. Of course, if the compiler can prove that the variable doesn't change elsewhere, then it's OK to memoize. But just assuming because it's strong pure is not correct.

Of course, it depends on the definition of "equivalent arguments".

-Steve

On Friday, 10 February 2023 at 18:01:56 UTC, Steven Schveighoffer wrote:

   An implementation may assume that a strongly pure function that returns a result without mutable indirections will have the same effect for all invocations with equivalent arguments. It is allowed to memoize the result of the function under the assumption that equivalent parameters always produce equivalent results."

In my experience, David Nadlinger's "Purity in D"[1] is a better source of truth than DMD or the spec when it comes to pure.

As far as I can tell, the spec and "Purity in D" use the same definitions for "weakly pure" and "strongly pure". David also describes "pure factory functions" (without calling them that) as "not [taking] any arguments with mutable indirections". So we got that right, too.

But on memoization, David says: "When coming across a pure function with immutable parameters, only the identity of the arguments has to be checked in order to be able to optimize several calls down to one [...]. On the other hand, if an argument type contains indirections and is only const, somebody else could modify the data between two calls, requiring »deep« comparisons that might not be feasible for large data structures in the runtime case, or extensive data flow analysis in a compiler."

Looks like the spec misses the requirement of having only immutable parameters.

[1] https://klickverbot.at/blog/2012/05/purity-in-d/

On Friday, 10 February 2023 at 19:33:26 UTC, ag0aep6g wrote:

Though I just realized that that can be interpreted two ways:

1. The function does not have any parameters with mutable indirections. I.e., const is ok. This is what DMD does.
2. The function cannot be called with mutable indirections. I.e., const is not ok.

I think the first interpretation is the intended one, but I can't say I'm sure.