Conforming literals 0017 messes up code sharing between C++ and HLSL due to non portable float literal suffices

[devshgraphicsprogramming]

Which proposal does this relate to?
0017 - https://github.com/microsoft/hlsl-specs/blob/main/proposals/0017-conforming-literals.md

Describe the issue or outstanding question.

HLSL will now treat 4.5 as a float literal, while most C++ compilers treat 4.5 as a double literal.

This is an issue when one wants to share lets say a header of mathematical constants between HLSL and C++ (like our bezier and polynomial solvers).

No combination of suffices is portable across Clang, GCC and MSVC that would make the 4.5 a double both in HLSL and C++.

While I understand that in HLSL the default literal type must be float32 for performance reasons, we must have a solution thats more sane than wrapping every literal in a FLOAT64_LITERAL() macro to get the correct compiler specific suffices.

Additional context

Personally I'd add support for the sized f16, f32 and f64 suffices introduced by C++23.

[devshgraphicsprogramming]

I'd actually implement this first https://en.cppreference.com/w/cpp/language/user_literal

compiling with C++23 just to have f16,f32,f64 suffices on the Host side is a bit of a steep ask.

[simondeschenes]

On our side, the most important compatibility is with GLSL, MSL, Nvidia slang and a proprietary console shader language.
They all consider a literal without suffix to be a float.

• GLSL and the proprietary console shader language consider the s/S suffix to be for short and us/US for unsigned short.
• MSL doesn't have support for double.
• The suffix for double already changes between languages, if we were using double, we'd need to use a macro:
  • GLSL uses lf/LF as the suffix
  • The proprietary console shader language uses d/D as the suffix
  • Nvidia slang uses l/L as the suffix

Compatibility with C++ on the literal side isn't quite important because there are a lot of other in compatibilities between HLSL and C++ like structure member alignment, no 8-bit types, bool being 4 bytes... We already use a specialized code generator for code that needs to be shared between shaders and C++.

In our case, we only ever need to share structure definitions with C++ not functions. This is not the same requirements as @devshgraphicsprogramming.

I feel like we'd need a command line switch for the HLSL compilers to switch between the "shader standard" suffixes and the "C/C++" suffixes. -fuse-c-literals for example. It could also be #pragma literal c at the top of the file.

[llvm-beanz]

I feel like we'd need a command line switch for the HLSL compilers to switch between the "shader standard" suffixes and the "C/C++" suffixes. -fuse-c-literals for example. It could also be #pragma literal c at the top of the file.

This is the kind of thing I'm pretty vocally opposed to. We do not want flags to the compiler that change basic language behaviors. That dramatically increases our testing matrix and leads to difficult to identify, reproduce and resolve bugs.

[simondeschenes]

Understood. Well, we don't have control over C++ and changing the current behavior would bring us back to where we started with spurious double appearing or the wrong data written through Store functions when called with a literal (8 bytes written instead of 4).

So, I really wish we won't go back. But I also wish C++ had a suffix for doubles (and for short).

[devshgraphicsprogramming]

C++23 has kinda low adoption, and doesn't introduce a suffix for short literals. So IMHO user defined literal suffices are probably the most useful for everyone.