Notes about Secure HLSL

Hi Myles,

Thanks for publishing the Secure HLSL wiki page!
Here are my comments, split into sections:

## Compatibility

> Secure HLSL aspires to be source-compatible with almost all existing HLSL
shaders.

Why do you want to support the case of having multiple main() functions for
different shader stages?

> The #include preprocessor directive in HLSL is not present in Secure HLSL

Most of the shader codebases (HLSL and whatnot) that I had a pleasure to
work with used some sort of include mechanism to share common parts of
code. Is your idea to require the existing HLSL adopters to have a
pre-processor step and concatenate the code on their side first before
passing to WebGPU?

> The texture HLSL type is not present in Secure HLSL, nor is the sampler
HLSL type present in Secure HLSL.

I don't understand this part. It says neither texture or sampler types are
present, yet it doesn't mention them in "The following HLSL types are not
present in Secure HLSL" list.

## Scope

What I would expect from Secure HLSL is to restrict and specify the
existing HLSL syntax, so that we can securely adopt it. However, the
document lists a number of extra features that don't appear to be strictly
necessary for securing HLSL:

- generics
- pointers
- array references
- operator overloading

These features are nice to have for a language in general, but they appear
to be secondary (if not tangential) to the primary goal of the spec and
WebGPU effort in general.

## Efficiency

> All variables live for the lifetime of the program

Wouldn't this blow up the register occupancy of such programs? If the
shader compiler is supposed to optimize this requirement out for variables
not visible outside of their scope, then it appears to me that this would
complicate the compiler and/or hinder compiling performance.

Couldn't you only require global lifetimes for the variables being pointed
to?

> If an argument to any built-in function is NaN

Built-in functions are expected to run fast. I'm worried that putting
checks in all the arguments would heavily penalize arithmetic-heavy
programs.

> Denormalized floats must not exist

Is that also the approach WebGL group has taken?

## Other

> As such, Secure HLSL includes a "Logical Mode" which conforms to the
requirements of these languages.

There should be no need to avoid mentioning the elephant in the room by
name ;)

Thanks,
Dzmitry