tc39
Be more clear on use cases
My experience using caches and memoization is that although they are handy for solving algorithmic problems and in competitive programming, in production code it's often more desirable to handle caching/memoization on a different layer of the application.
One example is on my work in ICU; we often have issues where objects are cached in multiple different places (e.g., the data pipeline, within ICU library code, and within client code). This creates hard-to-find bugs and increased memory usage. In ICU4X, we made the decision long ago to make caching an explicit decision by the client and not have any hidden, internal caches.
Given that there is no one-size-fits-all approach to caching, I feel that this proposal should do more to lay out the motivating use cases and why memoization is the best way to solve those use cases.
I certainly agree: we need a lot more specific use cases in the explainer. This ties with #7.
I agree that I have seen memoization mostly used in algorithms, although the memoization React hook might be a prominent UI-level exception. We will collect examples and post them here and in the explainer before Stage 2.
(I am also hopeful that, by making its cache parametrizable, Function.memo would be useful across many situations with different caching needs. It would be a convenient way to use caching with a convenient interface: n-ary function calls. This is especially convenient for recursive algorithms.)
