I like this feature.

I feel like this might suffer from the same fundamental type problem as #56481, where differing driver behaviour could cause problems.

Hopefully the below demonstrates how Cache::integer('count') would throw an exception for Redis but work well with a database driver. I wonder if these differences in types returned need to be improved before we look at this one, otherwise it is only useable in certain scenarios.

Redis

<?php

use Illuminate\Support\Facades\Cache;
use Illuminate\Support\Facades\Route;

Route::get('/', function () {
    Cache::store('redis')->put('count', 1);

    dump(
        Cache::store('redis')->get('count'),
    );

    Cache::store('redis')->increment('count');
    Cache::store('redis')->increment('count');

    dump(
        Cache::store('redis')->get('count'),
    );
});

Database

<?php

use Illuminate\Support\Facades\Cache;
use Illuminate\Support\Facades\Route;

Route::get('/', function () {
    Cache::store('database')->put('count', 1);

    dump(
        Cache::store('database')->get('count'),
    );

    Cache::store('database')->increment('count');
    Cache::store('database')->increment('count');

    dump(
        Cache::store('database')->get('count'),
    );
});

It's a numeric string—couldn't this be cast?

On the other hand, we might adopt some Redis types for this feature:

• LIST (to an extent SET) – array_is_list()
• HASH – !array_is_list()
• JSON– could be used with jsonpath/dot notation

Valid point - thanks! Is integer() the only one affected here? Would casting be acceptable if the string is a valid integer?

Edit: applied this change for both integer and float.