Improve and tighten pure functions specification#1528
Conversation
jmdavis
left a comment
jmdavis
left a comment
There was a problem hiding this comment.
We've kind of tried to avoid making the terms "strong" and "weak" purity official, since it's really more of a range rather binary, and the difference really only applies to stuff like optimization, so I'm not sure that I'm all that enthused about using the term "strong" here like this, but it is a term that we keep having to use in discussions with regards to optimization - which is exactly how it's used here - and I don't really have a better suggestion. So, I guess that we should just go with it.
Aside from that possible nitpick though, everything looks good to me, and I think that we can live without fixing the nitpick.
spec/function.dd
Outdated
| $(P `pure` functions returning `void` will be always called even if it is | ||
| strongly `pure`. The implementation must assume the function does something | ||
| outside the confines of the type system and is therefore not allowed to | ||
| elide the call, even if it appears to have no possible effect.) |
There was a problem hiding this comment.
Wouldn't it be simpler to just say that pure functions returning void are not strongly pure?
There was a problem hiding this comment.
That's sort of implied by "... (b) returns a result without mutable indirections", if we agree that void functions don't return any result.
|
Should cover what happens when an exception is thrown by the pure function. I suggest regarding the exception thrown as its 'return value' as far as uniqueness and memoization rules go. |
|
@WalterBright will do with this PR. |
|
@WalterBright updated with no special requirements for exceptions so as to leave maximum freedom |
|
@WalterBright ping - guess we're now good |
spec/function.dd
Outdated
| may still be elided, or results be memoized, by means of traditional | ||
| inlining and optimization techniques available for all functions.) | ||
|
|
||
| $(P A function that accepts only parameters without mutable indirections and |
There was a problem hiding this comment.
whoops, should be: "A pure function" ?
|
@JohanEngelen thx fixed |
| assumptions related to memoization and references do not carry to the thrown | ||
| exception.) | ||
|
|
||
| $(P Destructors will always be called even if they appear to be strongly |
There was a problem hiding this comment.
"Destructors will always be called" is not want you want to say I think; instead, it should only say something about pure destructors.
Perhaps: "When a destructor is pure, it does not imply that it need not be called."
Maybe I am approaching this from too low-level viewpoint. When you write "destructors will always be called", do you mean it in the sense of debug-call-tracing-low-levelness, or in the high level sense of "the program will be executed as if destructors are always called" (thus allowing empty destructor calls to be eliminated)?
|
Can we now go forward with purifying |
6 participants
This is in keeping with the current implementation and tightens the spec to ensure no future shenanigans.