On Mon, 7 Sept 2026 at 17:10, Jakit Liang <[email protected]> wrote: > > Thanks again for pointing out that __bf16 is not a portable > replacement here. > > My standalone WSL reproduction was intended only to isolate the > condition observed in the editor integration. Instead of CLion, It > reproduced the > integration's -imacros input; it was not meant to claim that > __BFLT16_DIG__ should be defined for clangd, nor that libstdc++ > should support such a configuration. I will treat that integration > issue separately. > > Independently of that configuration issue, there is a library-internal > maintainability point. __gnu_cxx::__bfloat16_t is the existing > target-correct libstdc++ abstraction for the type of a bfloat16 > literal. It is deliberately defined in c++config using > __decltype(0.0bf16), rather than assuming that __bf16 has the > required meaning on every target. > > The local __format::__bflt16_t alias represents the same > target-dependent type. Obtaining that type again with > decltype(0.0bf16) duplicates the type-selection rule in <format>. > Referring to the existing __gnu_cxx::__bfloat16_t instead would keep > that rule in one place, preserve the target-specific semantics, and > keep <format> concerned only with consuming the already-established > type.
I don't agree that there's a maintenance concern here, in fact, it's the opposite. > This is not intended as a workaround for an invalid clangd macro > environment, and it does not change the fact that c++config itself > correctly needs the literal-based definition. The intended benefit is > simply to avoid a second, redundant target-dependent type deduction in > <format>. The point of the __format::__bflt16 definition is that it exists independently of other support for the C++23 std::bfloat16_t type. Although currently the definition of __gnu_cxx::__bfloat16_t is also defined pre-C++23, that should arguably be reverted. I made the __gnu_cxx::__bfloat16_t typedef available before C++23 in commit 1a566fddea212a6a8e4484f7843d8e5d39b5bff0 but then partially reverted that commit in 27d0cfcb2b33de07351d9cb26f62d04d7416716c and so there's no longer any need for __gnu_cxx::__bfloat16_t to be defined before C++23. If we reused that typedef in <format> but then reverted the change to __gnu_cxx::__bfloat16_t it would break the code in <format>. As currently defined, the code in <format> is not dependent on that other typedef and wouldn't be affected by changes to it. So I disagree that the two definitions are redundant, there is value to keeping them decoupled.
