Date: Thu, 22 Jan 2026 16:19:22 +0000
On Thursday, January 22nd, 2026 at 4:55 PM, Lénárd Szolnoki <cpp_at_[hidden]> wrote:
>
>
>
>
> On 21 January 2026 21:10:28 GMT, Ell via Std-Proposals std-proposals_at_[hidden] wrote:
>
> > On Wednesday, January 21st, 2026 at 8:03 PM, Jan Schultke via Std-Proposals std-proposals_at_[hidden] wrote:
> >
> > > On Wed, 21 Jan 2026 at 19:00, Thiago Macieira thiago_at_[hidden] wrote:
> > >
> > > > On Wednesday, 21 January 2026 09:41:12 Pacific Standard Time Jan Schultke
> > > > wrote:
> > > >
> > > > > > > Because the result of std::bit_cast has unspecified padding bits, so x =
> > > > > >
> > > > > > Unless we change std::bit_cast, which is what I am proposing.
> > > > >
> > > > > It would be an ABI break if you changed that, and compilers would
> > > > > essentially have to invent new ABI for all kinds of platforms to make this
> > > > > work, so the std::bit_cast that you're proposing is practically
> > > > > unimplementable.
> > > >
> > > > Why are you saying that? How is the behaviour of std::bit_cast ABI in the first
> > > > place?
> > >
> > > Because it's a function and returns by value, so it's limited by the calling conventions for the platform, and whether those preserve padding (they usually don't). Ergo, at least on a debug build, you're not getting any padding bits from a function call to std::bit_cast.
> >
> > I wonder how it plays with guaranteed RVO. If the return value conceptually initializes the result directly, shouldn't that technically include padding? (I guess that's mostly academic, since compilers don't do it in practice)
>
>
> Trivially copyable types don't get guaranteed RVO.
>
> https://eel.is/c++draft/class.temporary#3
Like I said in the other mail, I was thinking about types that aren't covered by this exemption (which could even be trivially copyable, contrived as it is). Theoretically, they should preserve padding under RVO, but in practice they don't <https://godbolt.org/z/Kn86Ko4Wf>. Like Jan said, changing that would affect ABI, so if anything, it's probably a (not very serious) defect.
>
>
>
>
> On 21 January 2026 21:10:28 GMT, Ell via Std-Proposals std-proposals_at_[hidden] wrote:
>
> > On Wednesday, January 21st, 2026 at 8:03 PM, Jan Schultke via Std-Proposals std-proposals_at_[hidden] wrote:
> >
> > > On Wed, 21 Jan 2026 at 19:00, Thiago Macieira thiago_at_[hidden] wrote:
> > >
> > > > On Wednesday, 21 January 2026 09:41:12 Pacific Standard Time Jan Schultke
> > > > wrote:
> > > >
> > > > > > > Because the result of std::bit_cast has unspecified padding bits, so x =
> > > > > >
> > > > > > Unless we change std::bit_cast, which is what I am proposing.
> > > > >
> > > > > It would be an ABI break if you changed that, and compilers would
> > > > > essentially have to invent new ABI for all kinds of platforms to make this
> > > > > work, so the std::bit_cast that you're proposing is practically
> > > > > unimplementable.
> > > >
> > > > Why are you saying that? How is the behaviour of std::bit_cast ABI in the first
> > > > place?
> > >
> > > Because it's a function and returns by value, so it's limited by the calling conventions for the platform, and whether those preserve padding (they usually don't). Ergo, at least on a debug build, you're not getting any padding bits from a function call to std::bit_cast.
> >
> > I wonder how it plays with guaranteed RVO. If the return value conceptually initializes the result directly, shouldn't that technically include padding? (I guess that's mostly academic, since compilers don't do it in practice)
>
>
> Trivially copyable types don't get guaranteed RVO.
>
> https://eel.is/c++draft/class.temporary#3
Like I said in the other mail, I was thinking about types that aren't covered by this exemption (which could even be trivially copyable, contrived as it is). Theoretically, they should preserve padding under RVO, but in practice they don't <https://godbolt.org/z/Kn86Ko4Wf>. Like Jan said, changing that would affect ABI, so if anything, it's probably a (not very serious) defect.
Received on 2026-01-22 16:19:32