-
Notifications
You must be signed in to change notification settings - Fork 335
Description
During the recent virtual face-to-face we discussed how extensions should be expressed with respect to the WGSL spec.
From the notes:
MM: match WebGPU, has conditional parts of the main spec. Was an intentional decision. Compressed textures as an example (e.g.: https://www.w3.org/TR/webgpu/#texture-compression-bc )
DM: follow main spec. Sort of wish it could just be a github branch
KG: hard to maintain
Consensus: Do what WebGPU does. (conditional inline with the spec)
MOD: what about unicode identifiers?
MM: Probably part of a larger feature pack that gets added
JB: is spec option in addition to versioning or only mechanism?
MM: agenda topic
In the WebGPU API, optional functionality are called "features" https://www.w3.org/TR/webgpu/#features
There is a "Feature Index" describing each feature. https://www.w3.org/TR/webgpu/#feature-index
WGSL has "extensions", and corresponding 'enable' directives.
But WGSL is a living spec, and it should support describing features during their lifecycle: before they are ready, when they are ready, and maybe even after deprecation. We should have a clear schema for describing these.
Suggest an addition to the "Language extensions" section something like:
An extension is either experimental or complete.
An experimental extension is not ready for general use. It may be changed at any time, and implementation support may be defective and incomplete.
A complete extension has been finalized: no further changes are expected, conformance tests are complete, and implementations supporting the feature pass those tests.
I don't think we need a "deprecation" concept just yet.