Adding filterByRegex method to Laravel Collections

[mohammadrasoulasghari]

Hi everyone! I'm considering contributing a new method to Laravel's Collection class called filterByRegex.

What it does

The method would allow filtering collections using regular expressions in a clean, readable way:

// Filter strings directly
$collection->filterByRegex('/^p/');

// Filter by a specific key
$users->filterByRegex('/@gmail\.com$/', 'email');

// Filter with dot notation for nested arrays
$data->filterByRegex('/PHP/', 'user.profile.bio');

// Filter with a callback
$products->filterByRegex('/2023/', fn($product) => $product->sku);

Why I think it’s useful

While this can be done with the existing filter() method, filterByRegex would:

• Make regex filtering more readable and explicit
• Support dot notation for nested arrays out of the box
• Follow Laravel’s pattern of having specialized filter methods
• Reduce boilerplate when working with regex filters

Questions

1. Would you find this method useful in your projects?
2. Are there any edge cases or parameters I should consider?
3. Is this something that belongs in the core Collection class or would it be better as a macro?

I’d appreciate your thoughts before submitting a PR. Thanks!

[henzeb]

While it is possible using filter, that one uses a closure. I would opt for altering filter to accept a string that executes the regular expression.

[mohammadrasoulasghari]

@shaedrich

Wouldn't this introduce ambiguity for developers? Since filter() is typically expected to receive a closure, passing a regex string might not be immediately obvious or intuitive.

[shaedrich]

Why would you assume that?

[crynobone]

There is no ambiguity here: Passing a string didn't work before

Doesn't filter() accept callable and not just Closure?

[mohammadrasoulasghari]

Why would you assume that?

My concern is that for some developers — especially those who are newer to Laravel — it might not be immediately clear, since filter() has traditionally worked with closures.
That said, I believe this bottleneck could be resolved if the documentation is clearly updated to reflect the new behavior.
Overall, I'm just bringing this up to help ensure we're choosing a clear and thoughtful path that keeps developer experience in mind.

[shaedrich]

Doesn't filter() accept callable and not just Closure?

Touché.

function filter(string|callable $filter)
{
    match (true) {
        @preg_match($string, '') !== FALSE => preg_match($filter),
        is_callable($filter) => call_user_function($filter),
        default => 'filter does not support arbitrary strings',
    };
}

[mohammadrasoulasghari]

Please tell me your opinions.