> Why would `compute_sha` not return a _BitInt(384)?

> If the machine the compiler is compiling for has registers or other constructs for handling 384-bit integers, then it certainly can assign a `_BitInt(384)` to such a register if it sees fit.

I have just explained that due to the alignment requirements it can't.

-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Jason McKesson via Std-Proposals
Sent: Thursday, September 4, 2025 03:36
To: std-proposals_at_lists.isocpp.org
Cc: Jason McKesson <jmckesson_at_gmail.com>
Subject: Re: [std-proposals] D3666R0 Bit-precise integers

On Wed, Sep 3, 2025 at 2:57 PM Tiago Freire <tmiguelf_at_hotmail.com> wrote:
>
> You can also do this:
>
> auto val = compute_sha(...);
>
> making _BitInt useless, don't need it, I just need whatever the actual concrete type "compute_sha" is returning.
> You haven't so much "got a type to be able to compute sha 384" but more like "look at this type that I used to copy data into".

Why would `compute_sha` not return a _BitInt(384)?

> > "The machine" is relevant to that conversation, but only to the extent that we can ensure that `_BitInt`'s definition does not prevent the compiler/machine from providing optimizations that the user needs.
>
> But that's precisely my point. _BitInt is a concept that is disconnected from any machine that actually exists.
> It doesn't matter how you interpret your programming language, the compiler cannot magically make the machine do something that it can't physically do just because that's how you coded it.

If the machine the compiler is compiling for has registers or other constructs for handling 384-bit integers, then it certainly can assign a `_BitInt(384)` to such a register if it sees fit.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals