Why must bitfields sum to a multiple of a byte?

[Timon Gehr]

On 07/31/2012 06:57 PM, Era Scarecrow wrote:
> On Tuesday, 31 July 2012 at 16:48:37 UTC, Andrej Mitrovic wrote:
>> On 7/31/12, Era Scarecrow <rtcvb32 at yahoo.com> wrote:
>>> 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 don't really know, I'm looking at this from a point of wrapping C++.
>> I haven't used bitfields myself in my own code.
>
> I'd say it's not a bug since C/C++ is free to reorder the fields you'd
> need to tinker with it anyways; HOWEVER if you still need to be able to
> have it then who's to stop you from doing it?
>
> I think more likely a flag/version or some indicator that you didn't
> make a mistake, such as making them depreciated so it complains to you.
> Kinda like how you can't make assignments in if statements or do useless
> compares, it's an error and helps prevent issues that are quite
> obviously mistakes.

This is obviously a mistake in the bitfield implementation. What else
could be concluded from the error message:

std\bitmanip.d(76): Error: shift by 32 is outside the range 0..31

Requesting a 32 bit or 64 bit member on the other hand is not a
mistake, and it is not useless, therefore the analogy breaks down.

(Also IMO, the once-in-a-year wtf that is caused by accidentally
assigning in an if condition does not justify special casing assignment
expressions inside if conditions. Also, what is an useless compare?)