Alternative fix for #6909: Use @cached annotation #6967
Conversation
Stale symbol errors can happen when inspecting symbols while comparing the trees before and after pickling.
Syntax: ``` @scala.annotation.meta.cached def foo = rhs ``` It's like a lazy val, except that - it's not synchronized - it uses `null` as uninitialized value - it can have given parameters Use the same logic for caching given aliases
Restricting `entered` and `enteredAfter` to class members is more a trap to fall into than a helpful check.
The new implementation does not optimize given aliases with pure paths as right hand sides to be vals anymore. The reason is that even a pure path might be expensive to compute so we might want the caching. And caching is cheap, so there's little downside. Therefore, it's attractive to go with the simpler two way choice: leave RHS as is, or wrap it in a memo.
There was a problem hiding this comment.
Hello, and thank you for opening this PR! 🎉
All contributors have signed the CLA, thank you! ❤️
Commit Messages
We want to keep history, but for that to actually be useful we have
some rules on how to format our commit messages (relevant xkcd).
Please stick to these guidelines for commit messages:
- Separate subject from body with a blank line
- When fixing an issue, start your commit message with
Fix #<ISSUE-NBR>:- Limit the subject line to 72 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line ("Add" instead of "Added")
- Wrap the body at 80 characters
- Use the body to explain what and why vs. how
adapted from https://chris.beams.io/posts/git-commit
Have an awesome day! ☀️
and add pos and neg tests
|
Out of curiosity, would this be available to userland code? I can definitely see it being useful, at least for folks who know what they're doing... |
|
It seems that this is very close to |
|
Maybe I'm not understanding the discriminating factors, but I think this feature deserves a first-class keyword rather than an annotation. |
|
In light of the progress made with the lazy vals design in #6979, it seems safer and more systematic to just use a lazy val for caching given instances. That leaves the question whether @cached in its present form should be made available as a macro. I am not sure about that anymore. It does not seem to belong in the language spec. The compiler will have some usage for @cached but it's not clear it's enough to warrant the expense of having to implement it. |
Instead of memo, have a @cached annotation. Usage example:
A
@cached defis like alazy val, except thatnullas uninitialized valueUse the same logic for caching given aliases