Why does hlsl not support constructors?

[fknfilewalker]

No description provided.

[llvm-beanz]

The short answer to your question is history. HLSL began its life as a C-based language (C not having constructors).

Constructors is an obvious feature of C++ that HLSL does not have, and we are considering adding it to a future version of the language. There are some complications that we need to design around. For example, HLSL doesn't support global initialization in a way that is quite the same as C++. Additionally we need to design the interaction between HLSL semantic annotations and global constructors. We also are considering the design implications of adding destructors to HLSL.

To help us weigh this request it would be very helpful if you could provide details about the use cases that would be interesting to you. That information will allow us to design the feature in a way that meets your needs and the needs of other developers, and it will help us prioritize the feature against the other features we're planning.

Thanks!

[fknfilewalker]

Interesting,
I am not thinking of anything fancy, more like variable initialization which can also include function calls. This should make code cleaner/safer and removes the need for explicitly calling initialization functions (which is extra code and can be forgotten resulting in errors).
Also this would increase compatibility with CPU side c++ code. Since GPU algorithms become more and more complex (ray tracing, inverse rendering, ....) the need for unit tests of GPU code increases. Having a common ground on the most basic c++ features would be very nice and I believe/hope this is doable without changing too much.

Not sure if I should make a new issue for this but I think it would be nice to give an option to change the syntax for passing values by reference too.

For instance:

void foo(inout float x, in float y);
// this could also be written like
void foo(float& x, const float& y);

Again this would make it more compatible to c++ and would not change any fundamental functionality and already maps very nicely to hlsl.
I hope these are reasonable ideas.

Edit: Why is there no overload for mat4x4 * float4 type operations?

Edit2:
If interfaces are used, why is it not possible to call a function like this

interface I;
class A : I;
class B : I;
void foo(I obj)

with all classes that implement the interface? I don't mean in a dynamic way, but statically?
I can already use templates to do the same thing

template<class T>
void foo(T obj);

[llvm-beanz]

So, I have some good news and some bad news for you (and probably some deeply confusing news)…

The good news is, the core of what you’re asking for (HLSL being more like C++), is the general goal and direction for the language.

The bad news is, it is going to take time to get there, and some things are deceptively difficult. HLSL doesn’t support pointers or references, and there are fundamental limitations in the DXIL definition that make it not possible to just start supporting pointers. We have discussed the possibility of limited pointer and reference support that we could do without changing DXIL, but we don’t yet have firm plans to make those changes.

The really confusing news here is that the difference between inout and & is a lot more than syntax. HLSL’s inout keyword models a copy-in/copy-out parameter calling convention, rather than an address-based call. This means that if you pass a global value as inout and use the global inside your function, they may have different values:

int Global;

void Fn(inout int G) {
  G += Global; // 1 + 1 = 2
  G += Global; // 1 + 2 = 3
}

void entry() {
  Global = 1;
  Fn(Global); // Global = 3
}

The absence of overloaded operations is likely because they haven’t been requested.

WRT Interfaces… Interfaces are complicated, and they aren’t part of a generics/interface/protocol system like you might see in other languages. interfaces can’t be used as parameters because they don’t represent an object type, they are more like an implementation contract. There is some documentation on how to user interfaces here

[fknfilewalker]

The good news is...

That is a good to hear and certainly a good target.

The really confusing news...

Not really asking for pointers but if you have plans for that I would not say no. I did not know that inout is that different but it makes sense to me now, always thought it is a reference.

The absence of overloaded...

It is just so strange because for float4 etc. it is there. Feels kinda incomplete without it...

WRT Interfaces…

Yes, I was already worried that it is like that

Anyway really looking forward to the future of hlsl, the community really needs a shading language that can keep up with what is currently being researched.

[devshgraphicsprogramming]

my 2 cents, any constructor would have to be noexcept which may make them not as useful as you'd think (forget plopping a lot of C++ code into HLSL and expecting it to run)