James Kominick

Unfortunately this won't work. `cached!` expands to a `lazy_static` block and a function def. The `lazy_static` block can't live directly in the `impl` block. (related #6)

I added a note on this to the readme (3dea1a1). I may be able to work around this limitation when adding a proc-macro version (brought up in #13)

Yes, that's definitely an option! The existing macros are in need of a re-think anyway

@Rahix , @kirhgoff - Yeah, the `cached` macros really need a redesign. Until that happens, could the issue of uncached "context" params be solved by using the `cached_key!` macro? This...

Nice, definitely would love a PR to add this functionality!

Hi @phayes , your understanding is correct in that it will cache both `Ok`s and `Err`s by default. If you only want to cache `Ok`s, then you can pass `#[cached(result...

Hm, so the readme is generated from the crate documentation in src/lib.rs (using cargo-readme, see the readme.sh script). There's actually links to each of the macros in the first paragraph,...

Thanks for the background info! - cache files: I think we would be better off requiring an argument on a new cache-type that specifies a cache-directory or a specific cache-file...

@jakobn-ai > a new cache-type My original thinking around this was that introducing serialize-ability to the existing cache types would mean that the type constraints would need to change to...

@jakobn-ai Good idea - yeah, I'd be ok with making the `UnboundCache.store` public for now as a workaround