Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

List of things to improve in the HLSL language #104

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
76 changes: 76 additions & 0 deletions proposals/0000-things-to-improve.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
<!-- {% raw %} -->

# List of Things to Improve in the HLSL Language
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if a proposal document is the right way to capture this? Any reason not to use issues for each thing? Then a proposal document can be written with a concrete proposal on addressing the thing-that-needs-to-be-improved.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've created this list based on a @llvm-beanz's suggestion that it would be helpful to have one place that lists all of the not-so-nice features and obscure constructs in the language. We can then refer to it when designing a new language version. Issues would probably too as long as they are labeled such that they're easy to find.


* Proposal: [NNNN](NNNN-things-to-improve.md)
* Author(s): [Helena Kotas](https://github.com/hekota)
* Status: **Design In Progress**

## Introduction

This document includes a list of features that we might consider removing in a
future version of the HLSL language. It includes things that:
- have unusual syntax or odd behavior
- are remnants of outdated features that are no longer used or relevant
- are construct that are generally considered "not very nice" from a language
point of view

## Motivation

We strive to evolve HLSL into a modern shader language. In order to so we need
to recognize odd, outdated or obscure features that are no longer used or that
we do not wish to support going forward.

## List of Things to Improve

### 1. Global variables outside of `cbuffer` context

All global variables declared outside of `cbuffer` context go implicitly into
`$Globals` constant buffer. Any initializers on global variables are ignored.

Possible solutions:
- Require all global variables to be declared withing `cbuffer` context and stop supporting `$Globals`
- Require any top-level global variable to be declared with `const` and report error if it is
initialized.
- Get rid of `cbuffer` entirely and just use `ConstantBuffer` instead so we have more regular syntax for other types of buffers.

### 2. Nested `cbuffer` declarations

Nesting of `cbuffer` declarations and allowing functions inside `cbuffer`
declaration context.

```c++
cbuffer CB {
int a;

cbuffer CB { // duplicate name ok
int b;

int foo(int x) {
return x * 2*;
};
}
};
```

This is equivalent to:

```c++
cbuffer CB {
int a;
};

cbuffer CB { // duplicate name ok
int b;
};

int foo(int x) {
return x * 2*;
};

```
https://godbolt.org/z/PeW4E3aj3

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My 2c: we should get rid of cbuffer entirely and just use ConstantBuffer instead so we have more regular syntax for other types of buffers.


## Acknowledgments