On 7/3/2024 6:47 PM, Steven Schveighoffer wrote:
> But... I'm thinking now, why not just specify that? If you use uint, this is the explicit layout, and any C compiler that doesn't implement that mechanism, D does not support bitfield compatibility.
> That would go a long way to alleviating any concerns that portability would be based on the whim of some C compiler.
> 
> This should be fine, because, as you say, everyone already does it that way. D has the opportunity to make this official.

AFAIK, no C compiler has bothered to document the details of their bit field layout.

As for D, it specifies that the layout will match that of the "associated C compiler".

We could add a "best practices" note in the spec.

On 7/4/2024 8:18 AM, Richard (Rikki) Andrew Cattermole wrote:
> As a consequence it does mean that you shouldn't be doing things like tagged pointers with it.

That's not a problem, either.

> And that's a problem since pretty much all new cpu designs are 64bit.

If you layout your fields the same way as the associated C compiler for that cpu does, you'll be just fine.

Walter Bright kirjoitti 3.7.2024 klo 21.04:
> 
> Then they won't be compatible with C bitfields.
> 

Were in agreement we should have two bit field types (A well-specified one that's `std.bitmanip` one, and the C-compatible one) if we count the library implementations. I don't think other people have issues with that either.

The question is, why does the C-compatible one have to be the language-level one? What's the problem in having `std.bitmanip` as the language level field while still providing the C-compatible bitfield via a DRuntime or Phobos API?

I have readen your take on this from the latest DIP revision:

> Many methods were proposed to deal with this. The only time the layout matters is with Usage No. 3, where the layout is imposed externally. For Usage Nos. 1 and 2, the particular layout does not matter. When it does matter, many alternatives are available:
> 
>     Use https://dlang.org/phobos/std_bitmanip.html#bitfields
>     If one sticks with one field type (such as int), then the layout is predictable in practice, although not in specification
>     Use custom functions to encode/decode fields
>     A bit of testing will show what a particular layout is, after which it will be reliable
> 
> The alternatives are easy enough, and Usage No. 3 is unusual enough, that the extra language complexity to support multiple layouts is not worth it. Note that the author would use a lot more bitfields if they were in the language.

This doesn't really answer the question though, because in my view at least we could just as rightfully write:

The objections revolve around discomfort with the layout being incompatible with the associated C compiler. Many methods are there to deal with this. The only time this is needed is Usage No. 2, where the layout is imposed externally. For Usage No. 1, C compatibility does not matter and for 3 it would be less practical to use, being implementation dependant. When C compatibility is needed, many alternatives are available:

    Use the C-compatible DRuntime bitfield API
    If one sticks with one field type (such as int), then the layout is same as with D in practice, although not in the C specification
    Use custom functions to encode/decode fields
    A bit of investigation will show what the C bitfield layout is, after which it can be translated to a D bitfield, possibly with `version` statements to deal with differences between compilers.

The alternatives are easy enough, and Usage No. 2 is nonstandard enough, that the extra language complexity to support multiple bitfield types at language level is not worth it. Note that the author does need to use mentioned alternatives a lot anyway to integrate with underspecified C types, such as `long`.

So, is there something wrong with this take?

Dukc kirjoitti 6.7.2024 klo 20.56:
> Note that the author does need to use mentioned alternatives a lot anyway to integrate with underspecified C types, such as `long`.

Actually this is an analogy I want to push. Ask yourself, why is `long` defined as exactly 64 bits in D? Why isn't it defined to have the same size as associated C `long`?

This is why language-level bitfields should not attempt to mimic C either, at least not by default.

On 7/6/2024 10:56 AM, Dukc wrote:
> The question is, why does the C-compatible one have to be the language-level one?

Because it's sooo convenient and it makes mixed C/D programs even easier.

User convenience can't be oversold, that's been hammered into me over decades.

On 7/6/2024 11:05 AM, Dukc wrote:
> Actually this is an analogy I want to push. Ask yourself, why is `long` defined as exactly 64 bits in D? Why isn't it defined to have the same size as associated C `long`?

Because a 32 bit C long is useless. It's a vestigial remainder from 16 bit programming.

Sensible C programmers use "long long" instead.

On Saturday, 6 July 2024 at 23:36:12 UTC, Walter Bright wrote:
> On 7/6/2024 10:56 AM, Dukc wrote:
>> The question is, why does the C-compatible one have to be the language-level one?
>
> Because it's sooo convenient and it makes mixed C/D programs even easier.
>
> User convenience can't be oversold, that's been hammered into me over decades.

And you cant find a way to do it that doesn't require D bitfields being built on shifting sands?

And it's a niche feature, in a niche situation, really how many people are going to be doing mixed C/D programs, and how many of them will need compatibility between C and D bitfields.

We should not be letting C idiocy infect the D language.

On Friday, 5 July 2024 at 16:48:29 UTC, Walter Bright wrote:
> On 7/3/2024 6:47 PM, Steven Schveighoffer wrote:
>> But... I'm thinking now, why not just specify that? If you use uint, this is the explicit layout, and any C compiler that doesn't implement that mechanism, D does not support bitfield compatibility.
>> That would go a long way to alleviating any concerns that portability would be based on the whim of some C compiler.
>> 
>> This should be fine, because, as you say, everyone already does it that way. D has the opportunity to make this official.
>
> AFAIK, no C compiler has bothered to document the details of their bit field layout.
>
> As for D, it specifies that the layout will match that of the "associated C compiler".
>
> We could add a "best practices" note in the spec.

D should not be adding language features that change their specification depending on what external C compiler happens to be attached to the project.

That is a ridiculous design.

You need to detox your brain of C. First it was C functions should be assumed safe, then it was string interpolation should be built around printf compatibility, and now it's bitfields should change their implementation based on whatever C compiler is attached?

The C part of your brain keeps leading you done one bad path after another.

On 7/7/2024 3:21 AM, claptrap wrote:
> D should not be adding language features that change their specification depending on what external C compiler happens to be attached to the project.

It always has - from its inception the struct member layout and alignment matches what C does. D needs to be a useful programming language, and effortless compatibility with C data layout makes it much more useful.