second draft: add Bitfields to D

[Jonathan M Davis]

On Monday, April 29, 2024 6:04:13 AM MDT Timon Gehr via dip.development wrote:
> On 4/29/24 08:44, Walter Bright wrote:
> > On 4/28/2024 3:30 PM, Timon Gehr wrote:
> >> However, I would still much prefer a solution that explicitly
> >> introduces the underlying `int`, `uint`, `long` and `ulong` fields,
> >> which would be the ones visible to introspection in a portable way, so
> >> that introspection code does not really need to concern itself with
> >> bitfields at all if it is not important and we do not break existing
> >> introspection libraries, such as all serialization libraries.
> >
> > I doubt introspection libraries would break.
>
> You are breaking even simple patterns like
> `foreach(ref field;s.tupleof){ }`.
>
> It would be a miracle if libraries did not break.

druntime and Phobos both specifically uses tupleof to look for the actual
members of a type which take up storage space in that type and whose address
can be taken. Traits such as std.traits.Fields do that and document it as
such. If bitfields show up as part of tupleof, I would fully expect that to
cause problems with any type introspection that operates on the member
variables of a type. The breakage may be minimal in practice due to the fact
that bitfields aren't currently part of the language, and it's only new code
which would encounter this problem, but any existing type introspection code
looking at fields is going to expect that all of those fields take up
storage space and that their address can be taken, so if it's given a type
which has bitfields, and those show up in tupleof, that code is not going to
work correctly.

Such code does already need to take unions into account (and there is _some_
similarity between those and bitfields), but it's going to have done that by
checking things like is(T == union), which won't help with bitfields at all.
And really, even if bitfields matched that, you wouldn't necessarily get the
right result anyway, because while both bitfields and unions have members
which are not proper fields on their own, the way they behave and take up
space in the type is completely different.

Maybe we should add a check for bitfields? Presumably, it would have to be
something more like __traits(isBitfield, member), since unlike with a union,
you can't check the type, and we're not adding a bitfields keyword, but
regardless of how you'd check whether something is a bitfield, existing type
introspection code is going to have to be updated in some fashion to take
bitfields into account, or it's going to do the wrong thing when it's given
a type that has bitfields. There's no way that bitfields are going to just
magically work correctly with code that does type introspection.

It does make sense that __traits(allMembers, T) would give you the
bitfields, but I don't think that it makes sense that tupleof would, since
you cannot take their addresses, but either way, it _will_ break Phobos code
if tupleof gives bitfields - and not in a way that would be easily detected,
because doing so would require having tests that used bitfields, which of
course, don't exist, because bitfields have to be added first.

- Jonathan M Davis