[202x][202y] Update proposals for correct targets

proposals/0001-hlsl-namespace.md

@@ -4,7 +4,7 @@
 * Author(s): [Chris Bieneman](https://github.com/llvm-beanz)
 * Sponsor: [Chris Bieneman](https://github.com/llvm-beanz)
 * Status: **Under Consideration**
-* Planned Version: 202x
+* Planned Version: 202y
 
 ## Introduction
 

proposals/0002-cxx-attributes.md

@@ -5,7 +5,7 @@
 * Author(s): [Chris Bieneman](https://github.com/llvm-beanz)
 * Sponsor: [Chris Bieneman](https://github.com/llvm-beanz)
 * Status: **Under Consideration**
-* Planned Version: 202x
+* Planned Version: 202y
 
 ## Introduction
 

proposals/0004-unions.md

@@ -4,7 +4,7 @@
 * Author(s): [Chris Bieneman](https://github.com/llvm-beanz)
 * Sponsor: [Chris Bieneman](https://github.com/llvm-beanz)
 * Status: **Under Consideration**
-* Planned Version: 202x
+* Planned Version: 202y
 
 ## Introduction
 

proposals/0005-strict-initializer-lists.md

@@ -6,7 +6,7 @@
 * Author(s): [Chris Bieneman](https://github.com/llvm-beanz)
 * Sponsor: [Chris Bieneman](https://github.com/llvm-beanz)
 * Status: **Under Consideration**
-* Planned Version: 202x
+* Planned Version: 202y
 
 ## Introduction
 

proposals/0006-reference-types.md

@@ -4,7 +4,7 @@
 * Author(s): [Chris Bieneman](https://github.com/llvm-beanz)
 * Sponsor: [Chris Bieneman](https://github.com/llvm-beanz)
 * Status: **Under Consideration**
-* Planned Version: 202x
+* Planned Version: 202y
 
 ## Introduction
 
@@ -41,7 +41,7 @@ References to any other address space will need explicit annotation.
 ### Expanded Operator Overloading
 
 Along with the introduction of references we can expand operator overloading to
-remove the restrictions introduced in HLSL 2021. 
+remove the restrictions introduced in HLSL 2021.
 
 Support for overloading operators that idiomatically returned references are
 prohibited in HLSL 2021. With the addition of limited reference support those

proposals/0007-const-instance-methods.md

@@ -4,7 +4,7 @@
 * Author(s): [Chris Bieneman](https://github.com/llvm-beanz)
 * Sponsor: TBD
 * Status: **Under Consideration**
-* Planned Version: 202x
+* Planned Version: 202y
 
 ## Introduction
 

proposals/0008-non-member-operator-overloading.md

@@ -6,7 +6,7 @@
 * Author(s): [Chris Bieneman](https://github.com/llvm-beanz)
 * Sponsor: [Chris Bieneman](https://github.com/llvm-beanz)
 * Status: **Under Consideration**
-* Planned Version: 202x
+* Planned Version: 202y
 * Related Proposal(s): [0006 Reference Types](0006-reference types.md)
 
 ## Introduction

proposals/0009-math-modes.md

@@ -4,7 +4,7 @@
 * Author(s): [Chris Bieneman](https://github.com/llvm-beanz)
 * Sponsor: [Chris Bieneman](https://github.com/llvm-beanz)
 * Status: **Under Consideration**
-* Planned Version: 202x
+* Planned Version: 202y
 * Dependencies: [0002 C++ Attributes](0002-cxx-attributes.md)
 
 ## Introduction
@@ -66,7 +66,7 @@ For example:
   }
 
   float fma2(float x, float y, float z) {
-    return [hlsl::math_mode(strict)] x * y + z; 
+    return [hlsl::math_mode(strict)] x * y + z;
   }
 ```
 

proposals/0020-hlsl-202x-202y.md

@@ -56,8 +56,21 @@ DXC and it is expected to cause potential disruption.
 
 Existing proposals that fall into this category are:
 * [Numeric Constants](/proposals/0003-numeric-constants.md)
+  * DXC Issue - [[202x] [0003] Numeric Constants](https://github.com/microsoft/DirectXShaderCompiler/issues/7218)
+  * Clang Issue - [[202x] [0003] Numeric Constants](https://github.com/llvm/llvm-project/issues/131808)
 * [Conforming Literals](/proposals/0017-conforming-literals.md)
+  * Completed in DXC - [[202x] Implementaiton of conforming literals](https://github.com/microsoft/DirectXShaderCompiler/pull/6572)
+  * Completed in Clang - [[HLSL] Implement 202x conforming literals](https://github.com/llvm/llvm-project/pull/91015)
 * [Loop Unroll Factor](/proposals/0022-hlsl-loop-unroll-factor.md)
+  * DXC Issue - [[202x][0022] Loop Unroll Factor](https://github.com/microsoft/DirectXShaderCompiler/issues/7219)
+  * Completed in Clang - [[HLSL] add loop unroll](https://github.com/llvm/llvm-project/pull/93879)
+
+In addition to the new features, HLSL 202x will remove features that were not
+fully supported by DXC. Issues tracking 202x feature deprecations:
+* [Effects Syntax](https://github.com/microsoft/hlsl-specs/issues/380)
+* [HLSL Interfaces](https://github.com/microsoft/hlsl-specs/issues/291)
+* [cbuffer variable initializers](https://github.com/microsoft/hlsl-specs/issues/259)
+* [`uniform` keyword](https://github.com/microsoft/hlsl-specs/issues/135)
 
 HLSL 202x will not include features for all differences between DXC and Clang.
 Some of the
@@ -68,8 +81,67 @@ have workarounds and may pose a barrier to adoption.
 
 ### HLSL 202y
 
-HLSL 202y shall contain features that expand HLSL. This is all other outstanding
-feature proposals.
-
+HLSL 202y is an opportunity to address some frequently requested features that
+we can deliver more quickly in Clang than in DXC. Some of the features in HLSL
+202y require significant changes to core language behaviors and will likely
+cause source compatibility issues.
+
+Two big areas of investment in HLSL 202y are overload resolution and object
+initialization. While the two areas are intertwined, we will discuss them mostly
+separately.
+
+#### Overload Resolution
+
+In Clang we've adopted overload resolution behavior more similar to C++. This
+causes some source incompatibilities as cited in the [clang
+docs](https://clang.llvm.org/docs/HLSL/ExpectedDifferences.html). Taking these
+behavior changes into HLSL makes HLSL's overload best-match algorithm more
+familiar and will produce ambiguous resolution errors instead of potentially
+choosing an unexpected overload when ambiguity exists in the source.
+
+Adopting C++ overload best match and set selection rules implements proposal
+[0007 `const` non-static member
+functions](https://github.com/microsoft/hlsl-specs/blob/main/proposals/0007-const-instance-methods.md).
+
+Adopting C++ language rules for the contexts in which overload resolution occurs
+implements proposal [0008 non-member operator
+overloading](https://github.com/microsoft/hlsl-specs/blob/main/proposals/0008-non-member-operator-overloading.md).
+
+#### Object Initialization
+
+Supporting [C++
+constructors](https://github.com/microsoft/hlsl-specs/issues/303) requires
+revisiting HLSL's approach where all objects support aggregate initialization
+(braced initializer lists), which makes it connected to proposal [0005 strict
+initializer
+lists](https://github.com/microsoft/hlsl-specs/blob/main/proposals/0005-strict-initializer-lists.md).
+
+HLSL 2021 & 202x have special rules for aggregate initializers such that the
+source-provided structure of braced initializer lists is ignored and an
+element-wise initialization is performed. This conflicts with objects having
+constructors, destructors, or user-provided conversion functions. It also
+conflicts with [`union`
+types](https://github.com/microsoft/hlsl-specs/blob/main/proposals/0004-unions.md).
+
+HLSL 202y adopts support for constructors and destructors, and C++'s rules for
+aggregate initialization.
+
+#### Other Mostly Free Features
+
+Other C++ features have made their way in via Clang's implementation preserving
+C++ constructs. A few notable features that we expect to standardize in HLSL
+202y are:
+
+* [`constexpr` functions](https://github.com/microsoft/hlsl-specs/issues/74)
+* [`constexpr` variables](https://github.com/microsoft/hlsl-specs/issues/21)
+* [`auto` variable declarations](https://github.com/microsoft/hlsl-specs/issues/24)
+* `static_assert`
+* [`bit_cast`](https://github.com/microsoft/hlsl-specs/issues/318)
+* `public`, `private` and `protected` access specifiers.
+
+Additionally, we do have some features that we're experimenting with in Clang
+which may or not make the cut for HLSL 202y. Those include:
+* [C++ lambdas](https://github.com/microsoft/hlsl-specs/issues/21)
+* [`union` types](https://github.com/microsoft/hlsl-specs/blob/main/proposals/0004-unions.md)
 
 <!-- {% endraw %} -->

proposals/0022-hlsl-loop-unroll-factor.md

@@ -4,37 +4,38 @@
 * Author(s): [Farzon Lotfi](https://github.com/farzonl)
 * Sponsor: [Farzon Lotfi](https://github.com/farzonl)
 * Status: **Accepted**
+* Planned Version: 202x
 * Impacted Projects: DXC & Clang
 
 ## Introduction
 
-This proposal seeks to unify the diverging behaviors between the agreed upon 
+This proposal seeks to unify the diverging behaviors between the agreed upon
 [spec for HLSL loop unroll](https://github.com/microsoft/hlsl-specs/pull/263)
 and the current behavior of DXC.
 
-The new spec wants to treat the unroll factor as a hint to the compiler for 
-partial loop unroll. The current behavior in dxc is that the unroll factor 
-specifies the maximum number of times the loop is to execute. 
+The new spec wants to treat the unroll factor as a hint to the compiler for
+partial loop unroll. The current behavior in dxc is that the unroll factor
+specifies the maximum number of times the loop is to execute.
 
-The DXC behavior was determined to violate user expectations by overriding 
-the existing loop termination conditions. Further the DXC behavior diverges 
-from how both clang and openCL treat the loop unroll factor which would have 
-made our port of HLSL loop unroll a bunch special cases instead of just 
-syntactic sugar that could sit on top of the existing loop unroll 
+The DXC behavior was determined to violate user expectations by overriding
+the existing loop termination conditions. Further the DXC behavior diverges
+from how both clang and openCL treat the loop unroll factor which would have
+made our port of HLSL loop unroll a bunch special cases instead of just
+syntactic sugar that could sit on top of the existing loop unroll
 implementations that exist in LLVM.
 
 ## Motivation
-The HLSL compilers transition to clang has resulted in a compat break between 
+The HLSL compilers transition to clang has resulted in a compat break between
 the [HLSL loop unroll implementation in clang](https://github.com/llvm/llvm-project/pull/93879)
-and the one in DXC. While there is an expectation that the new compiler will 
+and the one in DXC. While there is an expectation that the new compiler will
 not be fully compatible with the previous compilers, These compat breaks should
  be minimized when possible.
 
  ## Proposed solution
-In [HLSL 202X](0020-hlsl-202x-202y.md) the DXC implementation of the loop 
-unroll factor should no longer alter the  number of iteration executions. 
-Ideally the loop unroll factor will also become a compiler hint for partial 
-loop unroll. If this can not be done because of concerns of invalid DXIL 
+In [HLSL 202X](0020-hlsl-202x-202y.md) the DXC implementation of the loop
+unroll factor should no longer alter the  number of iteration executions.
+Ideally the loop unroll factor will also become a compiler hint for partial
+loop unroll. If this can not be done because of concerns of invalid DXIL
 generation then the loop unroll factor as a feature should be removed from DXC.
-Removal in this case means ignoring the unroll factor and issuing a warning to 
-inform the user.
+Removal in this case means ignoring the unroll factor and issuing a warning to
+inform the user.