Caching D中记忆函数的纯度

在D中记忆函数时，有没有聪明的方法来保持纯度

---

在缓存保存在RAM中的大型数据集的SHA1计算时，我需要这样做。

简短回答：选择内存化或纯度。不要试图两者兼得

详细回答：我不认为通过记忆来保持纯洁性是可能的，除非你使用强制转换来欺骗编译器，声称函数是纯洁的，而不是纯洁的，因为为了记忆，你必须存储参数和结果，这破坏了纯洁性，因为

纯
函数的首要保证是它们不访问可变的全局或静态变量（这是您能够记忆任何内容的唯一方法）

所以，如果你做了类似的事情

alias pure nothrow Foo function() FuncType;
auto result = (cast(FuncType)&theFunc)();

然后您可以将Func
视为是纯的，而不是纯的，但是接下来就要由您来确保函数从外部执行
pure
，包括处理编译器认为它可以更改返回可变类型的强
pure
函数的返回类型的可变性这一事实。例如，这段代码可以很好地编译

char[] makeString(size_t len) pure
{
    return new char[](len);
}

void main()
{
    char[] a = makeString(5);
    const(char)[] b = makeString(5);
    const(char[]) c = makeString(5);
    immutable(char)[] d = makeString(5);
    immutable(char[]) e = makeString(5);
}

即使返回类型总是可变的。这是因为编译器知道
makeString
是强
pure
的，并且返回一个不可能传递给它的值-所以，它保证每次都是一个新值，因此将返回类型的可变性更改为
const
或
immutable
不会违反类型系统

如果在
makeString
内部执行某项操作，当函数违反
makeString
始终返回新值的保证时，该操作涉及将函数强制转换为
pure
，则会破坏类型系统，根据您对
makeString
返回的值所做的处理，您将面临代码错误的风险

我意识到在没有函数指针的情况下获得纯度的唯一方法是强制转换函数指针，使其成为
pure
，但是如果这样做，那么您必须完全理解
pure
函数的保证是什么，以及编译器认为它可以用它做什么，以便完全模拟该行为。如果您返回
不可变的
数据或值类型，这会更容易，因为这样您就不会遇到编译器更改返回类型可变性的问题，但这仍然是一项非常棘手的工作

因此，如果您正在考虑将某些内容转换为纯

，请三思。是的，有可能做一些你无法做的事情，但这是非常危险的。就个人而言，我建议你决定是纯洁对你来说更重要，还是回忆录对你来说更重要，而放弃另一个。其他任何东西都是高风险的。

D允许在类型系统中表达的是一个不纯函数，它记忆一个纯函数

---

从概念上讲，memoizer也是纯的，但是类型系统没有足够的表达能力来实现这一点。你需要在某个地方作弊。

在什么意义上你希望函数是纯函数？你为什么需要这个通常，需求是相反的；函数应该是纯函数以允许记忆。@MarkusJarderot是的，函数需要是

纯函数

才能被记忆，但是如果你记忆一个函数，那么你就不能在另一个

纯函数

中使用该记忆结果，因为存储用于记忆的结果需要破坏纯度。因此，我假设Nordlöw正试图从

纯
函数内部使用memonization，而这正是他遇到麻烦的地方。如果函数内部memonization表是线程本地的，当然，我，记忆逻辑是否正确？@Nordlöw它是否在TLS中与纯度无关。当然，如果不是这样，那么当你将函数转换为纯函数时，你会遇到更多的问题，但问题是你被迫将函数转换为纯函数来进行记忆，这会打开一个巨大的蠕虫罐。如果您这样做，那么您必须以一种完全模仿类型系统对pure的要求的方式进行操作，并且不会违反其任何保证或破坏其任何优化。这就要求你非常有知识，非常小心。我甚至建议不要尝试。