On 3/9/2024 12:38 AM, Daniel N wrote:
> I guess it might be possible to make an even stronger guarantee, specifying that the current behavior is how it must work on windows and unix in order to be compliant with the D language spec. The same way we decided to define the common practise for integer wrapping and two's complement.

I've thought about that, and it seemed more straightforward to simply rely on the specified behavior of the associated C compiler. It's like D doesn't specify how floating point arithmetic works, just that it conforms to IEEE754.

On 3/9/2024 1:41 AM, Dennis wrote:
> I've shown that it's a problem when using bit bitfields in D's very own standard library (std.internal.unicode_tables)

I presume you mean

```
ulong x; // bit field sizes: 18, 12, 12, 4, 4, 4
```

https://github.com/dlang/phobos/pull/8880/files#diff-6649807e195867988f8292561430bf14abf6c9cf4cecbea53c7ac2fd436c3623R145

which is 64 bits. That should produce the same result across different C compilers, i.e. it shouldn't be a problem.

If I'm missing what the actual problem you've encountered is, please explain.


> and asked you to name one dub package that would benefit from D bit fields having C layout, which you didn't do.

The D compiler itself would, so using it in the D front end will effortlessly work with the C++ gdc and ldc backends.

I hate to say it, but it's still a complex solution to a rare and frankly trivial issue. With some care, one can write portable C bitfields.

On 3/11/2024 11:49 AM, Dennis wrote:
> That's great, but it's not what the DIP says currently, which is that the layout (for non-int) is implementation defined matching a C compiler.

It's the same story for longs. I had neglected to mention that in the DIP.


> It makes the comparison with C's varying `int` size, but the difference is that in that case, D sticks to its guns and keeps `int` 32-bits even when C would make it 16-bit. Perhaps the DIP could say: the layout in D is defined as X, which follows what C compilers do in practice.

D doesn't say what the alignment algorithm is, either, just that it matches the associated C compiler. It's always been that way, although it is not an accident. It was deliberate on my part. Nobody seems to notice this, it "just works", as it should.

As for 16 bit int D, that is a variant of D, not D. (It should perhaps be called "D16".) This is perfectly reasonable, because you will never be able to port non-trivial D code to D16 without major alterations (DMD itself will never be portable to 16 bit code). This frees the 99.99% of D programmers to not feel a need to contort their code to be "Standard-conformant" to 16 bit targets. I see the pointless self-torture of C programmers doing this all the time. (And in spite of these efforts, the C code is still not portable to those other unusual platforms.)

C would be better off if they took the same approach.


> Then programmers can be comfortable relying on the layout.

They already can rely on it, in practice.


>> The D compiler itself would, so using it in the D front end will effortlessly work with the C++ gdc and ldc backends.
> Those are extern(C++) classes, and they already have working bitfields.

There are currently no bit fields in the DMD front end source code, although there are some emulations of bit fields.


> They wouldn't be impaired by making bit fields in D consistent and predictable.

They are consistent and predictable now. Just like the D and C++ code reliance on ints being 32 bits, the endianess, and the alignment layout of the fields in the structs.

On Tuesday, March 12, 2024 1:31:49 AM MDT Martin Tschierschke via dip.development wrote:
> On Monday, 11 March 2024 at 17:57:58 UTC, Walter Bright wrote:
> > On 3/11/2024 2:46 AM, Martin Tschierschke wrote:
> >> On Thursday, 7 March 2024 at 04:26:56 UTC, Walter Bright wrote:
> >>> https://github.com/WalterBright/documents/blob/master/bitfields.md
> >>
> >> Typo:
> >>> Abstract
> >>> This proposal is for supporting bitfields in **C** the same
> >>> way they are supported in **C**.
> >
> > haha
>
> Sorry, but this is an ERROR on __your__ page, not a joke.

I expect that he was just laughing at his mistake.

- Jonathan M Davis

On 3/6/2024 8:26 PM, Walter Bright wrote:
> https://github.com/WalterBright/documents/blob/master/bitfields.md

Permanent link:

https://github.com/WalterBright/documents/blob/9b91ca5242e3e49ed807ee696675c078986aa51e/bitfields.md

On 3/7/24 20:42, Walter Bright wrote:
> 
> I.e. the layout is implementation-defined. That's correct. But in reality, it is fixed. There is no way that gcc on Linux is *ever* going to change the bit field layout, because it would break legions of existing code. It is cast in concrete, and is as immutable as it gets. The same for Microsoft C.
> 
> Furthermore, if you use `int` as the base type for bit fields, the layouts are all the same in all the C compilers I've encountered. For practical purposes, it is defined.
> 
> If you are still concerned about the layout, like you want a portable file format, don't use bit fields. Use std.bitmanip.

Well, that's kind of a foot gun. Portable by default is better.

On 3/7/24 05:26, Walter Bright wrote:
> https://github.com/WalterBright/documents/blob/master/bitfields.md

Still not a fan of this potentially not being portable between different compilers implementing the C calling convention on the same platform. But let's put that aside for a moment.

Let's say D bitfields are stored in memory in a non-portable way. How would a serialization library detect via introspection that these are bitfields and serialize them accordingly (in a portable way)?

In general, how to introspect on bitfields?