在我看來,功能純度的強大之處在於深層代碼路徑可以被驗證爲無副作用。什麼是人們在代碼樹的規模上的經驗,它可以在純粹的說明符中,以及代碼重用的程度如何?D中的純函數式編程
有幾件事情,我看到:
std.algorithm
大多沒有標記爲pure
,但也可能是主要是純潔的,無論是通過算法苛刻的實體化功能或混入的純度純淨版,或者由純度說明符本身是靜態多態的。
有用的轉換器,如to!string(someInt)
目前不是純粹的。
用戶定義的結構似乎有問題(如下面所示):
1.純析構函數在嵌套結構
2.即使在非嵌套結構
以下代碼純postblit功能目前給出了DMD 2.052多個錯誤贏得32位
struct InnerStruct
{
pure this(this) {}
pure ~this() {}
}
struct OuterStruct
{
InnerStruct innerStruct;
pure this(this) {}
pure ~this() {}
}
pure void somePureFunc()
{
OuterStruct s1 = OuterStruct(); // pure nested destructor does not compile
OuterStruct s2 = s1;
InnerStruct is1 = InnerStruct(); // pure non-nested destructor seems to compile
InnerStruct is2 = is1; // pure non-nested postblit does not compile
}
void main()
{
somePureFunc();
}
pure_postblit.d(18): Error: pure function 'somePureFunc' cannot call impure function '__cpctor'
pure_postblit.d(20): Error: pure function 'somePureFunc' cannot call impure function '__cpctor'
pure_postblit.d(18): Error: pure function 'somePureFunc' cannot call impure function '~this'
pure_postblit.d(17): Error: pure function 'somePureFunc' cannot call impure function '~this'
感謝您的意見。 我注意到實驗時純度的弱定義,它顯然非常強大,允許在純代碼中進行完全可變的OO編程,並且在創建惰性評估thunk或調度promise等時,強大的形式可以很容易地被meta - 對類型限定符進行編程。我認爲,要實現高度併發的願景,還需要有更多能夠置身於純信封之中。我提到的析構函數和postblit問題對我影響最大,因爲我需要在純代碼中引用count,你認爲它們是錯誤嗎? – John 2011-04-28 19:19:06
@John:是的,這些可能是錯誤的。 – dsimcha 2011-04-29 02:02:26