Dictionary members are always optional by default if they don't have required, so the ?s are not needed.

@kainino0x thanks for the quick review! PTAL

But hey, it translates into a beautiful ADT in rust :)

@jdashg I'm curious what looks gross to you. Is it the optionals being simple types like u32 and float, or something else?

I feel the same way a tiny bit, because it's not immediately obvious that null or unspecified means "load". Null/unspecified sounds like a "nothing" operation whereas "load" is not.

What if instead it were:

enum GPULoadOp { "load" };
...
(GPULoadOp or GPUColor) loadValue;

? Plus it leaves the enum open for future extension.

Null/unspecified sounds like a "nothing" operation whereas "load" is not.

I don't see this being the case because there is no longer any "operation" involved. If the user doesn't clear, they don't expect anything to happen (to that texture).

Sort of true, but in actual hardware and modern API concepts, the load isn't considered to be "nothing" either. I wouldn't want our mental model to move away from the native APIs.

I understand the concern. The pit of success is in encouraging the user to use clears where possible.
For example, the user draws a full-screen quad into a target. They don't particularly care about clearing, but doing so would be faster on a tiling GPU. Having the clear color as optional doesn't particularly encourage this.

In terms of API, ideally we want to express this type:

enum LoadOp {
  Load,
  Clear(Color),
}

Either the PR as it stands, or Kai's comment would at least make this non-redundant. I'm fine with either.

Discussed at the 6 May 2019 teleconference.

Agreement reached to proceed with Kai's suggestion.