base::flat_set usage within blink

[Stefan Zager]

Hello,

By default, base::flat_set and base::flat_map cannot be used inside blink. However, there are about a dozen carve-outs, and I'm wondering how people would feel about relaxing the restriction more generally.

My guess is that there are two primary reasons for the restriction:

- No support for base:: containers of garbage-collected types

- Mixing redundant/overlapping WTF and base containers could create a big mess

Are the other reasons I'm not thinking of?

How hard would it be to modify the blink GC clang plugin to forbid base:: containers of garbage-collecte types?

My motivation here is that there are cases (including one I'm struggling with right now) where structured data is stored in a base:: container in cc/, passed to blink/, and then passed back to cc/. In some cases blink does not use or modify the container; it's just a conduit. In those cases, we either need to do a pointless round-trip base->WTF->base conversion; or we need to add entries to audit_non_blink_usage.py which creates a blind spot for enforcement.

Thoughts?

[Jeremy Roman]

On Sun, May 31, 2026 at 2:01 PM 'Stefan Zager' via blink-dev <blin...@chromium.org> wrote:

Hello,

By default, base::flat_set and base::flat_map cannot be used inside blink. However, there are about a dozen carve-outs, and I'm wondering how people would feel about relaxing the restriction more generally.

My guess is that there are two primary reasons for the restriction:

- No support for base:: containers of garbage-collected types

- Mixing redundant/overlapping WTF and base containers could create a big mess

Yes, those are the major reasons. If we had no clear boundary at all, then it may require regular conversions back and forth within Blink, or major refactoring when a collection that didn't previously need to refer to a GC type starts needing to.

The blink/non-blink boundary isn't always ideal for this purpose, but is a pretty good approximation. Cases where a type is just passed through are typically a reasonable case for an exemption, and if done through a type alias or similar it might not even be picked up by audit_non_blink_usage.py at all.

Are the other reasons I'm not thinking of?

How hard would it be to modify the blink GC clang plugin to forbid base:: containers of garbage-collecte types?

My motivation here is that there are cases (including one I'm struggling with right now) where structured data is stored in a base:: container in cc/, passed to blink/, and then passed back to cc/. In some cases blink does not use or modify the container; it's just a conduit. In those cases, we either need to do a pointless round-trip base->WTF->base conversion; or we need to add entries to audit_non_blink_usage.py which creates a blind spot for enforcement.

Thoughts?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHOQ7J9Ocib%2BwAetZxg1cx-djJsg6-5zMWyqbmXVfvk1CdGxBw%40mail.gmail.com.