Optional constraints proposal

[juliusikkala]

Closes #18. Based on shader-slang/slang#7201 (comment). Implementation ongoing in shader-slang/slang#7422.

@csyonghe do I also add you as a co-author? The syntax is entirely based on your comments.

[juliusikkala]

Regarding syntax, opinions on where optional? If the optionality was attached to the type instead, like ?IThing or maybe IThing etc., it'd be less verbose and allow the short-hand syntax f<T: maybe IThing>(). It would also work in lists, like where T: IThing, maybe IAnotherThing, while the current syntax in the proposal needs separate where lines to do that. On the other hand, I feel that the optionality is a feature of the constraint and not the supertype, so in that sense it feels more "right" for the optionality marker to not be attached to the type.

(small anecdote; I've typo'd "where optional" as "where optionally" roughly 50% of the time so far 😄)

[csyonghe]

I am open to supporting T: maybe IThing as a syntax if we find it to be convenient, but as you pointed out, optionality is an orthogonal concept to the kind of constraints, so we will need a general syntax for it anyways that will work for e.g. type equality constraint, value constraint(in the future) etc.

[csyonghe]

what's the implementation status of this? should give it a number, e.g. 039. Otherwise looks good to me.

[juliusikkala]

The implementation status is that it was merged in shader-slang/slang#7422 but has an outstanding bug shader-slang/slang#9367 that makes it not function in many cases involving generics. I tried to fix that issue in shader-slang/slang#9149, but couldn't find a way to lower it in the desirable way. Due to that issue, I ended up refactoring my own code to not use this feature, so I currently don't have a motivating use case left for this.

If we do keep this feature, then I'll still take another attempt at fixing that bug sometime in the future.