Why must bitfields sum to a multiple of a byte?

[Era Scarecrow]

On Tuesday, 31 July 2012 at 16:59:11 UTC, monarch_dodra wrote:
> No, it's a bug. There is no reason for it to fail (and it 
> certainly isn't a feature).

  If I made two fields in a 64bit bitfield, each 32bits int's I'd 
like it to complain; If it's calculated from something else then 
finding the problem may be a little more difficult. But that's 
how my mind works, give you the tools you need to do whatever you 
want including shooting yourself in the foot (although you need 
to work harder to do that than C++).

> 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?

  That would be the one reason that makes sense; Course can't you 
align sections at 1 byte and then by the default afterwards? 
Course now that I think about it, some systems don't have options 
to do byte alignments and require to access memory at 4/8 byte 
alignments. This makes sense needing to support it.

> 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.

  I would think the bug only showed itself if you did int at 
32bits and ulong at 64 bits, not ulong at 32bits.

> 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?

  Ummm..... Yeah I think I see what your saying; And you're 
probably right a special case would be less easily documented 
(and more a pain) when it shouldn't need a special case.

> 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...