On 4/30/2024 3:00 AM, Timon Gehr wrote:
> On 4/30/24 05:14, Walter Bright wrote:
>> I do not recall exactly why this `ref` behavior was done for foreach, but it was either a mistake or was done precisely to make generic code work.
> 
> You mean fail silently.

No, I did not mean that.

On 4/30/2024 1:48 PM, Timon Gehr wrote:
> Well, I am bringing it up because the DIP draft ignores type qualifiers so far (and explicitly only lists unqualified types for support). What is happening with `shared` I think has not been fully pinned down, but last I heard the goal was to get implicit atomics.

Since a bitfield can be part of a shared object, of course the shared type should exist for it. But since you cannot take a reference to a bitfield, you're going to have to dip into @system code to manipulate it, and it's up to the programmer to figure out what to do.

Immutable means read only. I don't see any issue with that, either.

On 4/30/2024 6:43 AM, Timon Gehr wrote:
> No, more than one bitfield is valid at a time even if they have the same offsetof. This is definitely breaking expectations that used to be true.

Any expectations that there would be no two fields with the same offset were incorrect anyway, as that is what happens with anonymous unions.


>> std.bitmanip.bitfields also implements it as a union,
> No, this is not correct. It implements it as a field with accessors for different groups of bits. The only reason why `union` appears in that file is to support bitfields inside a union. This again highlights that those are not the same thing.

They are the same thing, it is not substantive what label is painted on it. Anonymous unions can lay fields on top of each other without explicitly labeling it as a union.


> I understand the underlying reality of all of those concepts and I still disagree that interpreting bitfields as a union is correct. There are bitfields and there are unions.

There is no value to that distinction. As I replied to Jonathan in this thread, D can have fields laying over the top of each other right now without any unions or bitfields declared.


> But it will include bitfields, and not the underlying "physical" variables.

If the introspection code does not take into account anonymous unions, it's already broken anyway.

```
struct S
{
    union
    {
        int a;
        int b;
        int c:32;
    }
}
```

On 5/3/2024 5:52 AM, Patrick Schluter wrote:
> Not true. x86 provides BMI1 instructions which are present in x86 CPUs at least since 2013.
> ARM also provides bit field instructions and quite a number of legacy CPU's also had bitfield instructions (m68k, NEC V30, Itanium, PowerPC, etc.).
> Doesn't change the issues with language bitfields

I'd be very surprised if it didn't work by reading the entire field first.

https://www.felixcloutier.com/x86/bextr

On 23/04/2024 1:01 PM, Walter Bright wrote:
> https://github.com/WalterBright/documents/blob/dcb8caabff76312eee25bb9aa057774d981a5bf7/bitfields.md

Randomly came across people talking about C bitfields, and how the non-defined bit layout is causing them problems.

https://twitter.com/__phantomderp/status/1786628836953604201

Turns out even they think they need control over the layout including predictable LSB..MSB byte by byte definition.

Making it default to C for the layout is not a good addition to the language.

On 5/4/24 03:45, Walter Bright wrote:
> On 4/30/2024 3:00 AM, Timon Gehr wrote:
>> On 4/30/24 05:14, Walter Bright wrote:
>>> I do not recall exactly why this `ref` behavior was done for foreach, but it was either a mistake or was done precisely to make generic code work.
>>
>> You mean fail silently.
> 
> No, I did not mean that.

Well, that is what it will do if you assign a value to the `ref` iteration variable.

On 5/4/24 04:07, Walter Bright wrote:
>>>
>> No, this is not correct. It implements it as a field with accessors for different groups of bits. The only reason why `union` appears in that file is to support bitfields inside a union. This again highlights that those are not the same thing.
> 
> They are the same thing, it is not substantive what label is painted on it. Anonymous unions can lay fields on top of each other without explicitly labeling it as a union.

This is explicitly called a `union`, so I really do not see what you are trying to say.

Bitfields do not imply union, but they can be in a union, e.g.:

```C++
#include <bits/stdc++.h>
using namespace std;

struct S{
    union{
        struct {
            unsigned int x:1;
            unsigned int y:1;
        };
        unsigned int z:2;
    };
};

int main(){
    S s;
    s.z=3;
    cout<<s.x<<" "<<s.y<<endl; // 1 1
    s.x=0;
    cout<<s.y<<" "<<s.z<<endl; // 1 2
    s.y=0;
    s.x=1;
    cout<<s.z<<endl; // 1
}
```

Clearly bitfields are a new and distinct way fields can share the same `.offsetof` in D. Before bitfields, such fields would overlap given they both were of a type with a positive size. With bitfields there is no such overlap.

BTW: what about `sizeof`? I think in C++ this is disallowed on a bitfield.

On 5/4/24 19:05, Timon Gehr wrote:
> On 5/4/24 04:07, Walter Bright wrote:
>>>>
>>> No, this is not correct. It implements it as a field with accessors for different groups of bits. The only reason why `union` appears in that file is to support bitfields inside a union. This again highlights that those are not the same thing.
>>
>> They are the same thing, it is not substantive what label is painted on it. Anonymous unions can lay fields on top of each other without explicitly labeling it as a union.
> 
> This is explicitly called a `union`, so I really do not see what you are trying to say.
> 
> Bitfields do not imply union, but they can be in a union, e.g.:
> 
> ```C++
> #include <bits/stdc++.h>
> using namespace std;
> 
> struct S{
>      union{
>          struct {
>              unsigned int x:1;
>              unsigned int y:1;
>          };
>          unsigned int z:2;
>      };
> };
> 
> int main(){
>      S s;
>      s.z=3;
>      cout<<s.x<<" "<<s.y<<endl; // 1 1
>      s.x=0;
>      cout<<s.y<<" "<<s.z<<endl; // 1 2
>      s.y=0;
>      s.x=1;
>      cout<<s.z<<endl; // 1
> }
> ```
> 
> Clearly bitfields are a new and distinct way fields can share the same `.offsetof` in D. Before bitfields, such fields would overlap given they both were of a type with a positive size. With bitfields there is no such overlap.
> 
> BTW: what about `sizeof`? I think in C++ this is disallowed on a bitfield.

Another example:

```C++
#include <bits/stdc++.h>
using namespace std;

struct S{
    union{
        unsigned int x:1;
        unsigned int y:1;
    };
};

int main(){
    S s;
    cout<<s.x<<" "<<s.y<<endl; // 0 0
    s.x=1;
    cout<<s.x<<" "<<s.y<<endl; // 1 1
}
```

On 5/4/24 19:21, Timon Gehr wrote:
>      S s;

I guess this should have been `S s={};` to ensure the POD struct is initialized.

On 5/3/2024 11:07 PM, Richard (Rikki) Andrew Cattermole wrote:
> On 23/04/2024 1:01 PM, Walter Bright wrote:
>> https://github.com/WalterBright/documents/blob/dcb8caabff76312eee25bb9aa057774d981a5bf7/bitfields.md
> 
> Randomly came across people talking about C bitfields, and how the non-defined bit layout is causing them problems.
> 
> https://twitter.com/__phantomderp/status/1786628836953604201
> 
> Turns out even they think they need control over the layout including predictable LSB..MSB byte by byte definition.
> 
> Making it default to C for the layout is not a good addition to the language.

All the tweet says is:

```
As they should.
(But now it's time for C and C++ to give users explicit layout control, so that eventually we can use our chairs on other more heinous programming criminals.)
```

I've responded thoroughly to every complaint about the layout. The only substantive external one is Linus', which is linked to in the DIP, and I responded to that, too.

If you don't like bitfields at this point, don't use them. If you need help getting a specific layout, post here and I can help you.