Ecma TC57 - HLSL

0001 - HLSL 202x and 202y

StatusRefinement
Author
Sponsor

Implementation Status

DXCClang
202xIn ProgressIn Progress
202yNot PlannedIn Progress

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, and the language is undergoing a significant transition as we work in Ecma TC57 to specify and standardize it. Since HLSL currently does not have a specification 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.

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

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 the first Ecma Standard. The goal will be to support this language variant in both DXC and Clang, although DXC may not be fully conformant.

HLSL 202y also provides an opportunity for more breaking changes. We have a set of C++ features we know we would like to expose in HLSL. This also provides the opportunity for changes where we can improve tooling for source code migration to newer language constructs.

Version Naming and Management

HLSL versions names match the intended year of completion. Unreleased versions may use placeholders until the year of their release is certain.

The next language version is HLSL 202x, which will be followed by HLSL 202y. It is implicit that features in HLSL 202x will be present in 202y as well.

HLSL 202x

HLSL 202x shall serve as a compatibility bridge between DXC and Clang. As TC57 specifies HLSL Clang shall be implemented to match the specification, and (where appropriate and reasonable) DXC will be updated to conform to the specified behavior. Most of the specification should match DXC’s existing behavior, so we expect only minimal changes to be required in DXC.

Existing proposals that specify behavior different from DXC’s implementation of HLSL 2021 are:

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

Overload Resolution

There are some areas where HLSL 202x will deviate significantly from DXC’s implementation. One key area is overload resolution. The algorithm used by DXC for overload resolution scores overloads with an integer score, and uses golf rules (lowest score wins) to determine the “best” candidate. The algorithm as implemented has many flaws, and is extremely difficult to accurately specify, so no attempt was made.

In the Microsoft draft specification 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.

This proposal suggests that all of these changes should be included in the HLSL 202x language specification despite DXC being non-compliant as we believe the behavior implemented by DXC is a bug not by-design.

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.

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