Ecma/TC57/2026/XY
Ecma/GA/2026/XY

1 Welcome, opening and meeting logistics

Chris Bieneman, chair of TC57, began the teleconference and welcomed attendees. Attendees were reminded of the committee’s code of conduct, Ecma’s IPR policy, and TC57’s royalty-free patent policy extension. All attendees were informed that the meeting was recorded and transcribed by Zoom for the purpose of note-taking, and directed to review the video recording and legal disclaimer if they were not familiar.

2 Approval of previous minutes

In addition to publication to the Ecma file server and distribution to Ecma members, the minutes are published as a pull request on GitHub.

2.1 Approval of the minutes of the virtual meeting of 14 April 2026

The minutes were approved. The committee confirmed they’d reviewed PR \#29 and the chair merged it.

2.2 Approval of the minutes of the virtual meeting of 28 April 2026

The minutes were approved. The committee confirmed they’d reviewed PR \#30 and the chair merged it.

3 Review of the agenda

The meeting’s agenda pull request was proposed and approved at the start of the meeting.

3.1 Editors’ report

3.2 Review new proposals

• 202x removals - \#25
• cbuffer contexts - \#26
• Restricted Array Bounds - \#27

3.3 Discussions

• Review and merge:
  • Basic Concepts Clause - \#23
  • Conversions Clause - \#24
  • Normative References Language - \#28
• Call for Consensus:
  • conforming literals to Refinement - \#15
  • overload resolution to Refinement - \#19
• Other discussions:
  • HLSL standard headers? - \#36
  • Which proposals should we review for 202x and 202y? - \#3
  • What does the committee think of a blog/newsletter?
• Call for review and merge on 26 May 2026
  • Expressions Clause - \#35
  • Declarations Clause - \#37

4 Editors’ report

There was no editors’ report today.

5 New proposals

The following proposals were presented for status of “under consideration”

5.1 202x removals - \#25

This proposal focuses on features from legacy HLSL compilers but are not a target of support anymore. The proposal is to either remove them from the specification entirely, or document them in a separate annex clearly identifying them as “nonstandard”.

• effects syntax
  • Leaves parser in a state that leads to unpredictable behaviour.
• interface keyword
  • Implemented differently across different compilers.
• uniform keyword
  • Does not have semantic meaning in all environments, leading to silent failure and unexpected outcomes.
• cbuffer initializers
  • Leads to effects in some environments, ignored silently in others. Proposal to explicitly disallow to prevent developer confusion.

The proposal was approved for consideration.

5.2 cbuffer contexts - \#26

This proposal aims to reduce unexpected behaviour when cbuffers and namespaces interact in HLSL. Stuffing namespaces inside of cbuffers results in turtles all the way down. Or up, as it were. Chris included examples in the proposal of diverging behaviour between DXC and FXC.

There was a non-blocking question from Steven Perron that will be followed up. The proposal was approved for consideration.

5.3 Restricted Array Bounds - \#27

DXC and FXC diverge in how they handle unbound arrays (the phrase “chaos can ensue” was used), with FXC taking a stricter approach. This proposal seems to normalise that behaviour by matching closer to what FXC does and limiting declarators of arrays of unknown size.

The proposal was approved for consideration.

6 Discussions

6.1 Review and merge:

6.1.1 Basic Concepts Clause - \#23, Conversions Clause - \#24

• These clauses were reviewed by Gregory Roth (Nvidia) prior to the meeting and left some open questions.
• Amongst others, the committee is undecided as to whether they are willing to merge in references to sections that do not yet exist within the document on the assumption that they will be added at a later date.
  • One such example of this is cxvalue, which is not yet included in the basic concepts clause but is not a standard term (and is used extensively in PR \#24 Conversions clause)
• The decision was made to delay merge and continue to refine these two clauses to be a bit more complete for their first merge.

6.1.2 Normative References Language - \#28

Aki proposed a small PR to update language regarding normative references to align with Ecma house style. While an editorial PR like this wouldn’t typically be brought to the full committee, it was presented for informative purposes. There were no objections, the PR was merged.

6.2 Stage advancement to refinement

6.2.1 conforming literals to Refinement - \#15

There were no objections to move this proposal to refinement.

6.2.2 overload resolution to Refinement - \#19

There were no objections to move this proposal to refinement.

6.3 Other discussions

6.3.1 HLSL standard headers? - \#36

Chris Bieneman opened the conversation of the question whether or not HLSL should align its headers with C++ header names. For example, DXC’s “enable if” construct (enable_if.h) is not consistent with C++’s (enable_if). This could be a matter of frustration for users who wish to share code across C++ and HLSL. The second consideration is whether or not things should be added to the std namespace if they do not match C++—a not-trivial undertaking to fully match.

Justin Bogner expressed concern sharing a namespace with C++ due to the fact that TC57 has no control over the decisions made in ISO-IEC/JTC 1/SC 22/WG 21 (The C++ Programming Language), the committee as a whole expressed similar variations on this concern.

Chris shared a proposal on DXC to move all HLSL built-ins into a namespace intended to address subtle differences in math functions. Hai Nguyen (Nvidia) pointed out that game engines frequently import either DirectX Math Library or GLM under the HLSL namespace, which results in two different and potentially conflicting cowpaths in usercode already.

Ultimately the group reached consensus on refraining from using suffix es on system headers, and without a “std” namespace. There is still an unresolved decision on hlsl namespace, Chris will introduce a new proposal.

6.3.2 What does the committee think of a blog/newsletter?

There appears to be an appetite from the broader community of implementors and consumers of HLSL to get regular updates on what’s new and changed, and what the committee is considering. The only concerns from the committee are around time commitment and community expectations, not around confidentiality during standard drafting.

Chris will return to the committee with a more concrete proposal regarding timing, possibly even aligned with the chairs’ report to the ExeCom.

6.3.3 Which proposals should we review for 202x and 202y? - \#3

Of the list of existing proposals that will potentially be brough to the TC57 process, the chair seeks feedback on prioritisation. In particular, if there are proposals for 202y that may better serve the standard by being moved up to 202x. The committee will review and discuss at a future meeting.

7 Any other business

Alexander Johnston from AMD requested representation on the editorial board, likely Alexander. It was so noted and approved.

The chair requested future PR reviews by reviewed with sufficient time to resolve comments before the next meeting.

The conversation took a brief detour to discuss how proposals and the TC57 HLSL standard should reference Microsoft’s hlsl-specification. The group was in agreement that the end result of TC57’s standard should stand entirely on its own, but to quote Justin Bogner (Microsoft) “Pretending the historical context doesn’t exist doesn’t help anyone.”

8 Next meetings

The next meetings will take place as Zoom video calls fortnightly. The next scheduled is on 28 May.

8.1 Past and Future Agendas

Agendas are viewable in GitHub and remain available in perpetuity.

9 Conclusion

The chair wrapped up the meeting and the call concluded.