SideEffectFree and lambdas (documentation review) - #8109
Conversation
Bring the Purity Checker chapter in line with the @SideEffectFree javadoc: creating a lambda or a local/anonymous class is not a side effect, a lambda's body is checked against the functional method's annotations, and @SideEffectFree on a method with a functional-interface parameter is also a requirement on that method's callers. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XCfsNnTrse2emqZorUyFej
This reverts commit 1718f43.
mernst
left a comment
There was a problem hiding this comment.
Please review my changes, in addition to the comments in this pull request. Thanks.
|
|
||
| \subsectionAndLabel{Functional-interface parameters}{purity-functional-interface-parameters} | ||
|
|
||
| For a side-effect-free method, the default type is \<@SideEffectFree> for any |
There was a problem hiding this comment.
This section is written with a heavy emphasis on side-effect-free methods -- so much so that I suggested changing the subsection title. I think that is a red herring. There can be a small subsubsection about defaulting for function-interface parameters of side-effect-free methods. But overall the focus should be on side-effect-free functional-interface parameters, no matter what kind of method declares them.
| governs both the call in the body and the obligation on the argument, | ||
| exactly as for any other method. | ||
|
|
||
| Suppose that \<sem> is a \<@SideEffectFree> method or constructor with a |
There was a problem hiding this comment.
I found the antecedents of referents hard to determine. Giving them names, such as sem here, will clarify the writing.
| \item | ||
| If the argument is a lambda, its body is checked directly and no | ||
| annotation on it is needed. | ||
| \item |
There was a problem hiding this comment.
How are items 2 and 3 not special cases of item 4?
This is the specification I intend to implement. I want to get your approval before finishing up the code. (I'll merge these changes in another branch with the actual code changes.)