The issue on github is, from our perspective, the explainer link (I realized I put the link in the Initial Public Proposal field instead of the Explainer field, sorry about that, I mis-understood what went where in the status dashboard.) I've fixed the link to act as the explainer at this point.
This is how we've been handling the other language features for WGSL so far. There is a requirement for any language feature, before it lands in the spec, that each of Mozilla, Apple and Google have agreed that we'll all implement the language feature, if we don't have that agreement then it doesn't land in the spec. dan On Tue, Jan 20, 2026 at 2:41 PM Alex Russell <[email protected]> wrote: > Thanks for all of this, Dan. Very helpful. > > In terms of "going first", the question is "are we going to be the first > engine to ship this to stable?"; that situation creates more risk for us, > so we dot i's and cross t's even harder in those cases. Is it reasonable > from your perspective to draft a small explainer if we are, indeed, going > to be taking this risk? > > Thanks > > On Wednesday, January 14, 2026 at 10:20:15 AM UTC-8 dan sinclair wrote: > >> The issue linked from the PR provides more context: >> https://github.com/gpuweb/gpuweb/issues/5339. Essentially, it enables, >> inside a WGSL shader, to take a texture/sampler variable and assign it into >> a `let`. Basically provides an alternate name at the moment. In the future, >> the bindless work will have methods which can return a texture or sampler >> and we'd like to be able to store those into local variables. >> >> So, this allows you to have have something like: >> >> ``` >> @group(0) @binding(0) var tex: texture_2d<f32>; >> >> @fragment fn main() { >> let a = tex; >> var res: vec4f = textureLoad(a, vec2i(1i), 0); >> } >> ``` >> >> With bindless it will become a bit more interesting (below is not >> finalized, still in discussion API, but works as an example): >> >> ``` >> @fragment fn main() { >> let a = getResource<texture_2d<f32>>(2); >> ``` >> >> removing the need to call `getResource` multiple times. >> >> Not sure what you mean by going to be shipping this first? We've landed >> the code in Chrome behind the enable-unsafe-webgpu flag. So, it will be >> accessible from Chrome if the flag is enabled. >> >> dan >> >> >> On Wed, Jan 14, 2026 at 11:13 AM Alex Russell <[email protected]> >> wrote: >> >>> Dumb question from a non-WGSL developer: what does this enable? Why do >>> we want it? There's no explainer and no example code in the linked PR: >>> >>> https://github.com/gpuweb/gpuweb/pull/5389/files >>> >>> Are we going to be shipping this first? >>> >>> On Wednesday, January 14, 2026 at 8:12:26 AM UTC-8 Vladimir Levin wrote: >>> >>>> LGTM2 >>>> >>>> On Wednesday, January 14, 2026 at 8:51:23 AM UTC-5 Yoav Weiss wrote: >>>> >>>>> LGTM1 >>>>> >>>>> On Tuesday, January 13, 2026 at 2:49:44 PM UTC+1 Chromestatus wrote: >>>>> >>>>>> *Contact emails* >>>>>> [email protected] >>>>>> >>>>>> *Explainer* >>>>>> *No information provided* >>>>>> >>>>>> *Specification* >>>>>> https://github.com/gpuweb/gpuweb/pull/5389 >>>>>> >>>>>> *Summary* >>>>>> Add a language feature to WGSL, `texture_and_sampler_let` that adds >>>>>> the ability to store texture and sampler objects into a let declaration >>>>>> in >>>>>> WGSL. >>>>>> >>>>>> *Blink component* >>>>>> Blink>WebGPU >>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebGPU%22> >>>>>> >>>>>> *Web Feature ID* >>>>>> webgpu <https://webstatus.dev/features/webgpu> >>>>>> >>>>>> *Motivation* >>>>>> To allow storing texture and samples in WGSL shaders into lets. This >>>>>> allows creating local names for what are usually global objects. >>>>>> >>>>>> *Initial public proposal* >>>>>> https://github.com/gpuweb/gpuweb/issues/5339 >>>>>> >>>>>> *TAG review* >>>>>> *No information provided* >>>>>> >>>>>> *TAG review status* >>>>>> Pending >>>>>> >>>>>> *Risks* >>>>>> >>>>>> >>>>>> *Interoperability and Compatibility* >>>>>> This feature has been approved in W3C GPU for the Web WG meetings >>>>>> including participants from Safari and Firefox. Meeting minutes: >>>>>> https://docs.google.com/document/d/1kTmVO9okQZOotWtCNDzRaF-rPXgyIVJ-u5PEe7rnjQc/edit?tab=t.0#bookmark=id.u8bh2sfreh45 >>>>>> >>>>>> *Gecko*: No signal Mozilla members have approved >>>>>> https://github.com/gpuweb/gpuweb/pull/5389 and requested during >>>>>> weekly standardization meetings that we postpone filing standard >>>>>> positions >>>>>> until we reach Candidate Recommendation (CR) status in Q4. >>>>>> >>>>>> *WebKit*: Closed Without a Position ( >>>>>> https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933 >>>>>> ) >>>>>> >>>>>> *Web developers*: No signals >>>>>> >>>>>> *Other signals*: >>>>>> >>>>>> *WebView application risks* >>>>>> >>>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>>> that it has potentially high risk for Android WebView-based applications? >>>>>> *No information provided* >>>>>> >>>>>> >>>>>> *Debuggability* >>>>>> *No information provided* >>>>>> >>>>>> *Will this feature be supported on all six Blink platforms (Windows, >>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>>>> No >>>>>> All platforms will eventually have support. Will immediately be >>>>>> available on Android, Android WebView, ChromeOS, Mac, and Windows, where >>>>>> hardware support is available. Linux is planned to have WebGPU support in >>>>>> the future, so this feature will become available when WebGPU does. >>>>>> >>>>>> *Is this feature fully tested by web-platform-tests >>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>>>> Yes >>>>>> WebGPU/WGSL have a conformance test suite ( >>>>>> https://github.com/gpuweb/cts) that is regularly pulled into >>>>>> Chromium and part of the testing of Dawn/Tint in Chromium. While the CTS >>>>>> can be embedded in WPT, the WebGPU team opted to keep it separate in >>>>>> Chromium testing to use a customized harness for robustness and >>>>>> performance. CTS: https://github.com/gpuweb/cts/pull/4490 >>>>>> >>>>>> *Flag name on about://flags* >>>>>> *No information provided* >>>>>> >>>>>> *Finch feature name* >>>>>> UnsafeWGSLFeatures >>>>>> >>>>>> *Rollout plan* >>>>>> Will ship enabled for all users >>>>>> >>>>>> *Requires code in //chrome?* >>>>>> False >>>>>> >>>>>> *Tracking bug* >>>>>> https://crbug.com/459500757 >>>>>> >>>>>> *Estimated milestones* >>>>>> Shipping on desktop 146 >>>>>> Shipping on Android 146 >>>>>> Shipping on WebView 146 >>>>>> >>>>>> *Anticipated spec changes* >>>>>> >>>>>> Open questions about a feature may be a source of future web compat >>>>>> or interop issues. Please list open issues (e.g. links to known github >>>>>> issues in the project for the feature specification) whose resolution may >>>>>> introduce web compat/interop risk (e.g., changing to naming or structure >>>>>> of >>>>>> the API in a non-backward-compatible way). >>>>>> *No information provided* >>>>>> >>>>>> *Link to entry on the Chrome Platform Status* >>>>>> >>>>>> https://chromestatus.com/feature/5102334940151808?gate=6582632798355456 >>>>>> >>>>>> This intent message was generated by Chrome Platform Status >>>>>> <https://chromestatus.com>. >>>>>> >>>>> -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMYH%3DOghv1DV-96VbGsWCGO6NCtGz1iR0NQP7iM5w22dscguMg%40mail.gmail.com.
