search

microsoft / hlsl-specs

HLSL Specifications
MIT License
123 stars 33 forks source link

Add a proposal to describe 202x and 202y #178

Closed llvm-beanz closed 7 months ago

llvm-beanz commented 7 months ago

I've talked about 202x and 202y in passing but haven't really written down my thoughts. This proposal is the start of writing down how I think we should classify the two language versions.

damyanp commented 7 months ago

I'm a little surprised to have a single proposal for 202x and 202y. I'd have thought that 202x would likely be nailed down much sooner than 202y. Is your thinking that these could be separated in the future? Or are they more inherently tied together than I understand?

llvm-beanz commented 7 months ago

I'm a little surprised to have a single proposal for 202x and 202y. I'd have thought that 202x would likely be nailed down much sooner than 202y.

The proposal structure is maybe a bit odd for this kind of topic. This isn't really intending to propose a specific features or set of features as much as a guiding principle and approach for planning our next two feature sets.

Is your thinking that these could be separated in the future?

I'm proposing them as effectively two release targets. We already have a whole bunch of features that we were kinda planning as candidates for 202x, and I'm suggesting we really push almost all of those out to 202y and provide a narrower scoped purpose for 202x.

Or are they more inherently tied together than I understand?

I think it is helpful to have some idea of the features we want in 202y because that knowledge can help inform some of the work going on in Clang so that we know how aggressively to disable C++ features under the HLSL mode. That said, we might actually not know what features need to go in 202x to help bridge users to Clang until we get further along in development.

llvm-beanz commented 7 months ago

The proposal looks complete enough to merge for further discussion. My only question is whether this should be split into separate proposals for 202x and 202y.

I think ultimately we will want separate proposals for each feature that goes into 202x and 202y, and some unifying document that lists which features go into each version.

damyanp commented 7 months ago

Ah, so the document contained in this PR will become a bit like an index to all the 202x and 202y proposals - and so when we write a proposal for #73 we'd update this doc to link to that?

llvm-beanz commented 7 months ago

Ah, so the document contained in this PR will become a bit like an index to all the 202x and 202y proposals - and so when we write a proposal for #73 we'd update this doc to link to that?

Yea, and we can use this to frame out the motivation and intention behind each of the releases so that we know which bucket features might fit into. I suspect we'll have more features that we would want to get into 202y than we'll have time for, so eventually we'll need to acknowledge a "202z" although I hesitate to name that anything since it might be a "203z" instead...