List of things to improve in the HLSL language #104
Conversation
proposals/0000-things-to-improve.md
Outdated
|
|
||
| ### 1. Global variables outside of `cbuffer` context | ||
|
|
||
| All global variables declared outside of `cbuffer` context go implicitly into `$Globals` constant buffer. If the variable has an initializer it gets ignored. |
proposals/0000-things-to-improve.md
Outdated
|
|
||
| ### 1. Global variables outside of `cbuffer` context | ||
|
|
||
| All global variables declared outside of `cbuffer` context go implicitly into `$Globals` constant buffer. If the variable has an initializer it gets ignored. |
There was a problem hiding this comment.
If the variable has an initializer it gets ignored.
A little ambiguous whether "it" refers to the variable or the initializer. Maybe "Any initializers on global variables are ignored".
| @@ -0,0 +1,69 @@ | |||
| <!-- {% raw %} --> | |||
|
|
|||
| # List of Things to Improve in the HLSL Language | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
proposals/0000-things-to-improve.md
Outdated
|
|
||
| All global variables declared outside of `cbuffer` context go implicitly into `$Globals` constant buffer. If the variable has an initializer it gets ignored. | ||
|
|
||
| We should either require all global variables to be declared withing `cbuffer` context and stop supporting `$Globals`, or we should require any top-level non-static global variable to be declared with `const` and report error if it is initialized. |
There was a problem hiding this comment.
Why are static global variables different here?
I'm wondering if we should avoid suggesting solutions in this document since debate over solutions might detract from the main purpose of it.
There was a problem hiding this comment.
I think it would be useful to list potential solutions without going to too much detail.
There was a problem hiding this comment.
I've removed the non-static. I've update it to list possible solution without going into too much of a detail and updated the PR description that this is not a place to discuss which solution is best.
proposals/0000-things-to-improve.md
Outdated
|
|
||
| All global variables declared outside of `cbuffer` context go implicitly into `$Globals` constant buffer. If the variable has an initializer it gets ignored. | ||
|
|
||
| We should either require all global variables to be declared withing `cbuffer` context and stop supporting `$Globals`, or we should require any top-level non-static global variable to be declared with `const` and report error if it is initialized. |
There was a problem hiding this comment.
This suggested solution implies that the only issue with global variables outside of cbuffer is that initializers are ignored. Is that the primary thing we're trying to solve here, or are there more reasons that $Globals is undesireable?
There was a problem hiding this comment.
@tex3d - would you have more to add here why we should get rid of $Globals constant buffer?
|
|
||
| ``` | ||
| https://godbolt.org/z/PeW4E3aj3 | ||
|
|
There was a problem hiding this comment.
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.
|
@hekota, thank you for starting to put this together! Because this is language-related we should probably instead have this over in https://github.com/microsoft/hlsl-specs/. I do wonder if this is something we should track as a proposal, or just as more general documentation though. Maybe we should start writing some docs around longer term language direction that we can collect in hlsl-specs? |
This PR starts documenting a list of features that we might consider removing in a future version of the HLSL language. It includes things that:
This list may include potential solutions for each item. The purpose of this PR is solely to document the proposed options. The discussion on which solution is optimal can be postponed for future consideration.