[ffigen] Feature Request: Built-in Regex Helpers for `Declarations.include` / `includeMember` / etc

[Ferry-200]

Problem

Declarations and related configuration types (Functions, Structs, etc.) provide customizable filtering via:

bool Function(Declaration decl) include;

Technically, users can implement regex filtering manually:

include: (d) => RegExp(r'^av_').hasMatch(d.originalName)

However, this is not ideal:

1. Too verbose and repetitive
   Every user who needs regex filtering has to implement the same lambda again and again.

2. No built-in utility or examples
   The API only ships convenient helpers like:

Declarations.includeSet(...)

which encourages exact-match only, and gives the impression that this is the intended usage.

3. Large native SDKs make this common
   When wrapping FFmpeg, system SDKs, large C/C++ headers, or thousands of generated entries, we rarely want:

• == someName
• in { name1, name2, ... }

Instead we want:

• prefix match (av_*)
• pattern exclusion (.*_private)
• module grouping (MIDI_.*)
• filtering autogenerated symbols (^_.*)

This is not a rare use case — it’s a core ergonomics issue.

Proposal

Add built-in helpers like:

Declarations.includeRegex(RegExp exp);
Declarations.excludeRegex(RegExp exp);

Or composite helpers:

Declarations.match({
  RegExp? include,
  RegExp? exclude,
});

So usage becomes concise:

Functions(
  include: Declarations.includeRegex(RegExp(r'^av_')),
)

or:

Declarations(
  include: Declarations.match(
    include: RegExp(r'^Foo'),
    exclude: RegExp(r'_internal$'),
  ),
)

Benefits

• Zero change to the existing callback model
• 100% backward-compatible
• Removes repetitive boilerplate
• Improves usability for large APIs
• Makes regex-based filtering an endorsed, documented feature

Why not “just write your own include”?

Yes, users can write:

include: (d) => RegExp(...).hasMatch(...)

But…

• Everyone ends up writing the same code.
• API provides built-ins for set filtering, renaming, member rules, etc., but regex is a glaring missing piece.
• Lack of convenience gives wrong impression that “exact matching is the intended mode”, which is not ideal.

This feature is not about capability — it’s about developer experience and completeness.

Thanks for considering!

[dcharkes]

I'd probably use String operations instead of regexes when regexes aren't needed: include: (d) => d.startsWith(...).

cc @liamappelbe who recently added some convenience APIs.