From a glance at the code it looks like enumset uses u128 if you need more than 64 bits, and then arrays of u64 if you need more than 128 bits. So we'd probably have the same ffi issues with u128 we are currently running into in gecko.

Due to the issue with u128 and ffi my suggestion is to split into the standard flags and native-only ones into two types. We are pretty safe with 64 bits for the standard flags for a long while I think and they are the ones Gecko relies on in its FFI. If it doesn't break wgpu-native we can consider non-ffi-safe solutons for native-only flags in the future but splitting them off already gives us 30 or so bits to spare so we are good for a while too.

sounds good! better to not take another dependency

I would still prefer to use enumset if we can - more specifically I really don't want to split the features, this is making the users bare the brunt of a minor internal issue. Many people's renderers have a single slot for features, one for limits, and this would force them to take on another slot for no gain on their end.

I think it's likely that we'll eventually run out of space for u128 too. Maybe we could consider moving these into a big feature flags struct (could be directly exposed to FFI)? We could still have convenience methods to get roughly the same ergonomics as the current setup. Or we could expose a struct publicly and internally use something else if we want to keep the representation compact.

I just tried to see if I could alter enumset to produce something that would work over ffi ( I don't think getting it to use arrays of u64 would be difficult), unfortunately just depending on enumset causes cbindgen to crash. Here is the quick and dirty experiment if anyone wants to play around: https://github.com/nical/ffi_flags_test

There's a variety of things we can do long term. Splitting the flags probably being the simplest but I'm not particularly attached to it. I would prefer that the solution works well over ffi (without us having to do manually rewrite the flags). If it has to be rewritten on our side, then so be it, but it has to work with cbindgen.

We still have 18 bits available, that gives some time for motivated individuals to fix enumset or try out other solutions.

Resolution from meeting 10 months ago:

CF: What to do with features #5247

• enumset does what we want. It is ffi safe but IF it can fit in a u64.. defeating the purpose
• native/web feature split? Would break API.
• Roll our own features type? Plain struct of u64s.
  • Winner. Make features an enum and implement bitflag utils.

I think enumset and the question of u128 are orthogonal, actually.

To be clear, I agree that we should use two u64s for FFI, at the very least, and likely as an initial iteration for opening up more feature bits. Later, it might be interesting to try using enumset as an implementation detail, which I suspect would have an easier API to deal with under the hood.

Is there a reason this needs to be compressed? It feels like a struct of bool feature flags would work pretty well for the public API, and internally it could still be compressed (either now or later). I mentioned this in an earlier comment but thought it might be worth reconsidering if this is ends up being a breaking change anyway.

There's precedent for this in Vulkan, e.g., https://docs.vulkan.org/spec/latest/chapters/features.html#VkPhysicalDeviceFeatures

Default initialization for a struct would also still work fine in Rust and C, so writing out the full struct wouldn't be necessary. The headers could eventually be versioned like Vulkan to support multiple structs over time (instead of adding fields).

That's a good point. The C header is already doing something completely different (using strings like JS), but that may be more ergonomic. The features struct shouldn't be that big that we need to aggressively de-duplicate. It would also allow for more complex types than Bool.