Why should `createView:texture_state` succeed for destroyed textures

[beicause]

cts/src/webgpu/api/validation/createView.spec.ts

Lines 333 to 343 in b507bd1

	g.test('texture_state')
	.desc(`createView should fail if the texture is invalid (but succeed if it is destroyed)`)
	.paramsSubcasesOnly(u => u.combine('state', kResourceStates))
	.fn(t => {
	const { state } = t.params;
	const texture = vtu.createTextureWithState(t, state);
	t.expectValidationError(() => {
	texture.createView();
	}, state === 'invalid');
	});

Shouldn't createView fail on destroyed textures like invalid textures?
spec
https://gpuweb.github.io/gpuweb/#dom-gputexture-destroyed-slot

[kainino0x]

No, we chose not to do that because it would only complicate things. Even if we added that rule, you could still have a TextureView that points to a destroyed texture (create the view first, then destroy the texture), so all other validation already needs to handle that case. This would just add another state (invalid because parent texture was already destroyed) to the list of possible states (valid and parent texture is alive, invalid for any other reason, valid but parent texture now been destroyed).

[beicause]

@kainino0x But checking texture validity during createView is still valuable and matches the spec If the texture is destroyed, it can no longer be used in any operation.

wgpu currently checks it:
https://github.com/gfx-rs/wgpu/blob/e4e2c451d2d4f7585820260a728f7a14eacdf415/wgpu-core/src/resource.rs#L1892