Unexpected inout implicit type conversion

[Nielsbishere]

Description
Inout allows implicit casts such as float to uint. This is unexpected behavior and might end up causing a confusing debugging session.

Steps to Reproduce

struct PSInput {
    float4 color : COLOR;
};

void fun(inout uint v) {
    v = 1;
}

float4 PSMain(PSInput input) : SV_TARGET {
    float v = 2;
    fun(v);
    return input.color * v;
}

Actual Behavior
This should cause an error because a float should not be implicitly converted to a uint like this. For example if this was a uint& in C++ it would complain too.

Environment

• DXC version: trunk on 2023-06-16+ (shader-playground) and up.
• Host Operating System: N/A.

[llvm-beanz]

I realize that this behavior may be confusing, but it is the expected and correct behavior. HLSL inout parameters are passed by value in and out of the function and casted both ways.

We do have a language proposal tracking adding reference passing, which would behave more as you might expect.

I've been working on specifying the current behavior in our draft language spec. The gist of what happens is that when you pass an argument as an inout parameter it creates a cxvalue, which is an expiring cast value. The argument is casted to a temporary which is live through the function and casts back on function exit writing the casted result back to the argument.

[Nielsbishere]

Hi @llvm-beanz, thank you for your response. If there was a way to vote for that I would, because that would be very helpful. Is it planned to make it work similar to C#'s syntax? This is where you have to pass 'ref' before passing it to a function; imo this is cleaner than the C++'s way of doing it, which is not explicitly showing it's possible to modify. We have run into this in the past too because it's easy to miss whether a function is modifying something or not. Think off a Random struct which should be passed as inout, but the inout was missing which would cause the random re-roll to be discarded. If the ref keyword was enforced while calling the function, it would be obvious that the dev forgot the ref keyword because it's not passed as a ref. A few cases like that are easy to happen when the codebase gets big enough with multiple people with varying shader skills working on it.

[llvm-beanz]

HLSL's current evolution direction is to align more closely with C++ not C#, so we intend to add C++-like reference support not the C# ref keyword. We will not be changing the behavior of the inout or out keywords. References will be an addition to the language.

We're also working to fix some underlying issues with our ASTs to allow the compiler to issue more meaningful diagnostics about uninitialized variable use, but we don't intend to add required ref annotations.

[Nielsbishere]

Understandable, though unfortunate because I think it's very useful in clarity.