Possible required changes to discriminate schemas and resources from user-defined values.

[iwoplaza]

const CFG = {
  resourceType: 'buffer-usage', // A config value that happens to match with the "type" property of TgpuBufferUsage
  size: 32,
};

const getIndex = tgpu.fn([u32, u32]).does((x, y) => {
  // The "CFG" external is inferred to be a buffer usage, even though it's not one.
  // This, if we relied on resource's data types, would cause improper WGSL generation.
  return x + y * CFG.size;
});

This behavior can make things hard to debug for us and for the end developer.

Possible solutions

1. Rename 'resourceType' and 'type' props to something more obscure, and discriminate against that during WGSL generation, like "~resourceType" and "~type" respectively.
   • ❌ can still cause rare issues, if people choose to use '~' in their keys
   • ❌ it's hard to discriminate between TGPU-based values and user-defined values on the type-level.
2. Switch to using unique symbol props
   • ✅ has a nice side-effect of making it exist on the type-level
   • ✅ can be made inaccessible to the end user (by not exporting the symbol)
   • ❌ requires having only one TypeGPU instance per-realm (a sane requirement to have)
   • ❌ makes schemas unserializable (can always provide a "rehydration" mechanism)

[iwoplaza]

@mhawryluk @reczkok @aleksanderkatan Share your thoughts in the morning 🧠

The unique symbol approach would allow us to:

• Narrow down our APIs on the type-level, making auto-complete a lot cleaner.
• Reduce the risk of end-developers depending on our internals, so we can refactor with more confidence.
• Remove most of the INTERNAL_ type variants, as the internal API could be accessible through symbol properties instead.

[iwoplaza]

Good resource on how Jotai handles double-module detection:

https://newsletter.daishikato.com/p/detecting-dual-module-issues-in-jotai