New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lazy vals on Either should probably be defs #797
Comments
Imported From: https://issues.scala-lang.org/browse/SI-797?orig=1 |
@DRMacIver said: The problem is that x holds onto x.swap which holds onto x.swap.swap which... You get the idea. I'm more and more convinced that making any of these lazy vals is useless and actively dangerous. |
@mcdirmid said: |
Geoffrey Alan Washburn (washburn) said: In trunk, and in the 2.7.1 branch, I've converted most of the uses of lazy val to def. I left isLeft and isRight as think that they are unlikely to hold onto an unbounded amount of memory. If someone can prove me wrong, let me know and I'll change them as well. |
@DRMacIver said: While I'm making suggestions, wouldn't it be better if Either were a sealed abstract class so you could get pattern match warnings? |
@ijuma said: This is not unexpected because lazy vals involve a volatile read for thread-safety reasons (if I am not mistaken) and instanceof checks are intrinsic operations in recent JVMs. |
Geoffrey Alan Washburn (washburn) said: Further suggestions are welcome, but put them in new tickets to make them easier to keep track of separately. |
@ijuma said: |
@odersky said: |
If you look at scala.Either, it has a lot of lazy vals:
http://www.scala-lang.org/docu/files/api/scala/Either.html
These should probably all be defs. The results are extremely lightweight, and the allocation is probably comparably expensive to the laziness overhead so the fact that there are lazy vals just increases the memory overhead per instance of Either unneccessarily.
The text was updated successfully, but these errors were encountered: