Re: Notes about Secure HLSL

Thanks Myles for the document, here are my notes too, both on the document
and some of the discussions on this thread.

## Preprocessor and multiple entry-points

Not having #includes seems ok because you can do it in Javascript easily.
I'd argue that for the same reasons the rest of the preprocessor isn't
needed either, in particular since there isn't a good spec for how the C
preprocessor works which would be a source of incompatibilities.

Having multiple entry-points of different stages sounds ok, and is
supported in SPIR-V.

My suggestion for code reuse it to expose linking at that API-level. Some
modules could be pure-libraries and contain no entry-points while others
contain entry-points but some declared symbols are unimplemented. Module
linking could produces fully implemented modules with entry-points which
can be used for pipeline creation. Such linking would allow factoring of
the validation and translation cost too, and maybe some of the native
shader compilation cost.

## Builtin types

Why remove the [RW]ByteAddressBuffer? It is important to allow
heterogeneous data in buffers. It could be done with
StructuredBuffer<uint32_t> and casts but that's not ideal imho.

## Variables

Having things "as-if" local variables have a global lifetime sounds ok. It
corresponds how things work in native APIs where program-global register
allocation happens, and allows taking pointers to the variables (which
would then have their lifetime extended to that of the pointer).

## Safe pointers and array references.

The SPIR-V logical addressing mode doesn't allow null pointers, how would
this feature be translated? I suggest that pointers should always be
initialized and "null" doesn't exist.

Array-references are syntactic sugar around global arrays so I don't think
they are needed. Also there's a way to implement them for "thread" and
"threadgroup" address spaces (the only spaces they can be used with in your
proposal) such that they are assignable and translate correctly to SPIR-V.

It is unlikely that we can require KHR_variable_pointer anytime soon, so
the content of the "Logical Mode" could be merged in the pointer and
arre-ref sections and treated as a hard constraint.

## Out Of Bounds accesses

The trapping behavior described sounds extremely expensive to implement and
doesn't even match with the "discard" fragment shader operation. Penalizing
correct shaders to implement the trapping doesn't sound good and imo this
is a place where having a "one of the following happens" statement would be
ok. Same thing for NaN propagation and denorm floats.

## Syntax features

No comment on the design of these. Their complexity reinforces my concerns
about having incompatible implementations.

## High-level takeway

The document presents an HLSL++ that removes some of the ancient stuff of
HLSL and adds both pure-syntax features and a safe-pointer feature. There's
a small incompatibility with SPIR-V that (null pointers) that would be easy
to resolve.

Out of all the additional features, only the safe pointers are compelling
since they actually expose more features of the underlying platform. All
the others increase the complexity of the language compared to HLSL
resulting in even more interoperability concerns.