Immutables: Any call for a cachedHash or lazyHash?

[radifalco]

It may already be supported and I just missed it but what I'm wanting is something like a lazy hash. I like prehash but I don't like having to create the hash in every constructor, that's overhead for stuff that will never call hashCode. Can we have a lazyHash option? Works just like the default but adds a volatile int hashCode so that computeHashCode() is only called if the volatile field is zero?

[elucash]

Thank you for suggestion! It seems that this was requested a while ago, I even checked if this was not already implemented. I cannot easily find those conversations, maybe prehash=true was enough for those cases. As about the feature itself: it is nice to have, there's, probably, no need for volatile, it should be fine to recompute hash in presence or race condition assuming that it will be always computed to the same value and that the change to the fields will be observed eventually to all threads. The drawback (probably imaginary) is that unlike the case of prehash there will be no longer the situation where all fields are final: I've heard "rumors" of special "immutable" optimizations, but given that this is the way java.lang.String is implemented with a lazy hash code, this should not be a big deal. So nowadays I see we can implement this more or less effortless under special cacheHashCode style flag. Want to double check the interest in this (?).

Also, for any such piece of functionality, I would kindly ask to provide PR to documentation ;)
(this is a usual recommendation, though from now on I'll be more insisting on this, will have to add a PR template...)

[asereda-gs]

I have prepared a PR #1093