HLSL Specifications

0020 - HLSL 202x and 202y

StatusUnder Review
Author
Sponsor
  • Impacted Projects: DXC & Clang

Introduction

This proposal seeks to provide a framework for defining the next two versions of the HLSL programming language. It seeks to define HLSL 202x as a bridge between DXC’s implementation and Clang’s implementation, and HLSL 202y as the next major feature release.

Motivation

The HLSL compiler is undergoing a massive transition moving to Clang. Since the HLSL language is not formally specified and existing implementations disagree about fundamental behaviors, the new compiler will not be fully compatible with the previous compilers. This will create three conflicting implementations.

This poses a challenge for users as they seek to migrate to Clang. Sources used with DXC may not be compatible with Clang by preventing the ability to switch to Clang piecemeal or being able to A/B test shaders.

Version Naming and Management

HLSL versions names match the intended year of completion. Historically we missed with HLSL 2021 not completing the implementation and deployment in 2023. Due to schedule uncertainty and a desire to not repeat that mistake, future versions have placeholder names.

The next language version is HLSL 202x. HLSL 202y will release after 202x. As we near the final release of 202x the release name will change to the target year. The same will follow for 202y.

The expectation is that HLSL x is a placeholder integer value less than y. All features added to HLSL 202x will be implicitly inherited by HLSL 202y.

Proposed Solution

This proposal adopts the development of two new language versions for HLSL in parallel. The proposal adopts a narrowly focused HLSL 202x which will be supported by both DXC and Clang, and a wider focused HLSL 202y feature release which will only be supported by Clang.

HLSL 202x

HLSL 202x shall contain features that bridge compatibility between DXC and Clang. This shall be limited to cases where Clang’s implementations do not match DXC and it is expected to cause potential disruption.

Existing proposals that fall into this category are:

In addition to the new features, HLSL 202x will remove features that were not fully supported by DXC. Issues tracking 202x feature deprecations:

HLSL 202x will not include features for all differences between DXC and Clang. Some of the differences, are not expected to have meaningful difference to users, or have reasonable source compatible workarounds. HLSL 202x is specifically for differences that do not have workarounds and may pose a barrier to adoption.

HLSL 202y

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. 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.

Adopting C++ language rules for the contexts in which overload resolution occurs implements proposal 0008 non-member operator overloading.

Object Initialization

Supporting C++ constructors requires revisiting HLSL’s approach where all objects support aggregate initialization (braced initializer lists), which makes it connected to proposal 0005 strict initializer lists.

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.

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:

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:


 Edit on GitHub