There's a method compute which takes a key and a callback parameter. If there's no value for the given key, the callback is used to create the value and stored in the cache.

The problem is the method is context sensitive, i.e. it uses wantarray, propagates the context to the callback, and stores its return value in a different way based on the context.

But it's perfectly fine to store a value in a cache in scalar context and later retrieve it in list context - and the current implementation might fail, because it tries to apply array dereference in list context. Moreover, if the callback is context sensitive and returns something else in scalar versus list context, you never know which value is stored in the cache - it depends on which context you first called compute in.

What should we do? Calling the callback twice to store both the values is crazy (and might break code if it uses the callback to e.g. generate a unique id).

If it was upon me to decide, I'd remove context sensitivity from the method. If you want to store an array reference, provide a callback that does so.

Just for illustration, here's a test that passes with the current implementation (suitable to be pasted into lib/CHI/t/Bugs.pm):

sub test_141024 : Tests {
    my $cache = CHI->new( driver => 'RawMemory', global => 1 );
    my $callback = sub { wantarray ? 'list' : 'scalar' };

    my $scalar = $cache->compute( 1, undef, $callback );
    my @array = $cache->compute( 2, undef, $callback );

    is_deeply( $cache->get(1), 'scalar' );
    is_deeply( $cache->get(2), ['list'] );

    eval { my @array2 = $cache->compute( 1, undef, $callback ) };
    like( $@, qr/Can't use string \("scalar"\) as an ARRAY ref while "
+strict refs"/ );

    $cache->set( 3, ['in_list'] );
    is_deeply( $cache->get(3), ['in_list'] );
    my @foo = map $cache->compute( $_, undef, $callback ), 3, 4;
    is_deeply( $foo[0], 'in_list' );
    is_deeply( $foo[1], 'list' );
}
[download]

I'm not sure the bug has a good fix.

Thanks for your excellent analysis - I am inclined to agree with this conclusion but there may be some other concern we haven't considered. Either way it would have been good to see a response on the ticket from one of the maintainers.

Perhaps you might respond to the ticket yourself with a summary (and link back here)? Might jog things along - you never know.

---

🦛

> Perhaps you might respond to the ticket yourself

I did.

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

The single release by the ASB was to fix a warning reported 3 years earlier. Maybe somebody needs to remind HAARG that he still has co-maint permissions. He's very active with upriver dists.