https://github.com/WalterBright/documents/blob/2ec9c5966dccc423a2c4c736a6783d77c255403a/bitfields.md

Adds introspection capabilities.

https://github.com/dlang/dmd/pull/16444

On 5/6/24 01:08, Walter Bright wrote:
> https://github.com/WalterBright/documents/blob/2ec9c5966dccc423a2c4c736a6783d77c255403a/bitfields.md
> 
> Adds introspection capabilities.
> 
> https://github.com/dlang/dmd/pull/16444

Thanks, this is an improvement (though I think there would be ways to not require complex special cases in introspective code that does not deeply care about bitfields).


It seems these sentences are stale and should be deleted:

> There isn't a specific trait for "is this a bitfield". However, a bitfield can be detected by taking the address of it being a compile time error.

> A bitfield can be detected by not being able to take the address of it.


This is still wrong and should be fixed:

> The value returned by .sizeof is the same as typeof(bitfield).sizeof.

(Bitfields may have a smaller memory footprint than their type. You can just move it to the `.offsetof` and `.alignof` section and use the same wording.)


I am not sure about this:
> shared, const, immutable, __gshared, static, extern
> Are not allowed for bitfields.

Some elaboration is needed. For example: A `const` object can contain `const` bitfields even if the bitfields themselves were not declared `const`. What happens in this case?


Regarding the "Controversy" section:

The problem is not that there are no alternatives to bitfields (clearly there are), it is that they have the nicest syntax and semantic analysis support and yet they have pitfalls. It would be good to give more cumbersome syntax to those cases where pitfalls are in fact present.


> If one sticks with one field type (such as int), then the layout is predictable in practice, although not in specification

I mostly care about practice. (E.g, D's specified floating-point semantics are completely insane, but LDC is mostly sane and portable by default, so I have not been forced to change languages.)

> A bit of testing will show what a particular layout is, after which it will be reliable

No, absolutely not, which is the problem. If the behavior is not reliable, then testing on any one platform will be insufficient.

Portability/deployability is a big selling point of D, and we should be wary of limiting that for no good reason.

> Note that the author would use a lot more bitfields if they were in the language.

Which is why there should be basic protections in place against pitfalls.

On 5/21/2024 9:44 AM, Patrick Schluter wrote:
> Does it support the :0 syntax of C fields?

yes

On 5/24/2024 4:51 AM, Timon Gehr wrote:
> (E.g, D's specified floating-point semantics are completely insane,

I presume you are talking about doing intermediate computations as 80 bit floats. This was inevitable with the x86 prior to XMM. With XMM, floats and doubles are evaluated with XMM instructions that do 32/64 bit respectively.

On 5/25/24 00:21, Walter Bright wrote:
> On 5/24/2024 4:51 AM, Timon Gehr wrote:
>> (E.g, D's specified floating-point semantics are completely insane,
> 
> I presume you are talking about doing intermediate computations as 80 bit floats. This was inevitable with the x86 prior to XMM. With XMM, floats and doubles are evaluated with XMM instructions that do 32/64 bit respectively.
> 

It was avoidable, as even the x87 allows controlling the mantissa size (which is insufficient but "more" correct) or flushing floats and doubles to memory.

D compilers are allowed by the spec e.g. to use 64-bit XMM registers to compute with 32-bit float intermediates, with incorrect rounding behavior.

On 5/24/2024 11:52 PM, Timon Gehr wrote:
> It was avoidable, as even the x87 allows controlling the mantissa size (which is insufficient but "more" correct) or flushing floats and doubles to memory.

Flushing it to memory was correct but was terribly slow.


> D compilers are allowed by the spec e.g. to use 64-bit XMM registers to compute with 32-bit float intermediates, with incorrect rounding behavior.

Nobody implemented that.

On Saturday, 25 May 2024 at 07:47:13 UTC, Walter Bright wrote:
> On 5/24/2024 11:52 PM, Timon Gehr wrote:
>> It was avoidable, as even the x87 allows controlling the mantissa size (which is insufficient but "more" correct) or flushing floats and doubles to memory.
>
> Flushing it to memory was correct but was terribly slow.
>
>
>> D compilers are allowed by the spec e.g. to use 64-bit XMM registers to compute with 32-bit float intermediates, with incorrect rounding behavior.
>
> Nobody implemented that.

Just saw "Excess precision support" in the gcc changelog, which might interest you.
https://gcc.gnu.org/gcc-13/changes.html#cxx

"-std=gnu++20 it defaults to -fexcess-precision=fast"

I was aware of -ffast-math but not that the seemingly harmless enabling of gnu dialect extensions would change excess-precision!

On 5/26/2024 1:05 AM, Daniel N wrote:
> I was aware of -ffast-math but not that the seemingly harmless enabling of gnu dialect extensions would change excess-precision!


Supporting various kinds of fp math with a switch is just a bad idea, mainly because so few people understand fp math and its tradeoffs. It will also bork up code that is carefully tuned to the default settings.