Why must bitfields sum to a multiple of a byte?

[monarch_dodra]

On Tuesday, 31 July 2012 at 16:16:00 UTC, Era Scarecrow wrote:
> On Tuesday, 31 July 2012 at 15:25:55 UTC, Andrej Mitrovic wrote:
>> On 7/31/12, monarch_dodra <monarchdodra at gmail.com> wrote:
>>> The bug is only when the field is EXACTLY 32 bits BTW. 
>>> bitfields works quite nice with 33 or whatever. More details 
>>> in the report.
>>
>> Yeah 32 or 64 bits, thanks for changing the title.
>
>  I wonder, is it really a bug? If you are going to have it fill 
> a whole size it would fit anyways, why even put it in as a 
> bitfield? You could just declare it separately.
>
>  I get the feeling it's not so much a bug as a design feature. 
> If you really needed a full size not aligned with whole bytes 
> (or padded appropriately) then I could understand, but still...
>
>
>  And I'm the one that changed the title name. Suddenly I'm 
> reminded of south park (movie) and the buttfor.

No, it's a bug. There is no reason for it to fail (and it 
certainly isn't a feature).

Maybe the user wants to pack an "uint, ushort, ubyte, ubyte" 
together in a struct, but doesn't want the rest of that struct's 
members 1-aligned?

Maybe the user needs a 32 bit ulong? This way the ulong only 
takes 32 bits, but can still be implicitly passed to functions 
expecting ulongs.

Maybe the user generated the mixin using another template? For 
example, testing integers from 10 bits wide to 40 bits wide? 
Should he write a special case for 32?

...

Now I'm not saying it is big bug or anything, but it is something 
that should be supported... Or at least explicitly asserted until 
fixed...