On Monday, 8 July 2024 at 23:29:15 UTC, Walter Bright wrote:
> 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.

You have completely missed the point. Struct layout doesn't change, it's fixed, it doesn't depend on what C compiler is attached.

It's not C-compatibility, but letting the under specification of C bitfields basically infect D. Its the tail wagging the dog. Or leaky implementation. If I have a D program that links a dll or static lib also written in D, they could have incompatible bitfield layouts.

You could fix this by specifying the layout for D bitfields, and using extern(C) when compatibility with the relevant C compiler is required. D already does that for classes and functions...

On Tuesday, 9 July 2024 at 10:57:02 UTC, claptrap wrote:

>
> You have completely missed the point. Struct layout doesn't change, it's fixed, it doesn't depend on what C compiler is attached.

The layout is fixed, but alignment and padding are implementation specific.

>
> It's not C-compatibility, but letting the under specification of C bitfields basically infect D. Its the tail wagging the dog. Or leaky implementation. If I have a D program that links a dll or static lib also written in D, they could have incompatible bitfield layouts.
>
> You could fix this by specifying the layout for D bitfields, and using extern(C) when compatibility with the relevant C compiler is required. D already does that for classes and functions...

`extern(C)` does not affect the layout of anything, as far as I know. It only impacts name mangling and calling convention. Using it to change layout would be a new feature.

When I worked on Derelict and BindBC, I would have loved to have had bitfields in D. And I would have expected them to line up with the associated C compiler out of the box, because that's what already happens with structs.

On 7/9/2024 3:57 AM, claptrap wrote:
> You have completely missed the point. Struct layout doesn't change, it's fixed, it doesn't depend on what C compiler is attached.

I'm sorry to say, it does.


> You could fix this by specifying the layout for D bitfields, and using extern(C) when compatibility with the relevant C compiler is required.

I've posted in the other thread simple means to lay out portable bitfields. More language features are not required.

On Tuesday, 9 July 2024 at 11:58:14 UTC, Mike Parker wrote:
> On Tuesday, 9 July 2024 at 10:57:02 UTC, claptrap wrote:
>
>>
>> You have completely missed the point. Struct layout doesn't change, it's fixed, it doesn't depend on what C compiler is attached.
>
> The layout is fixed, but alignment and padding are implementation specific.
>
>>
>> It's not C-compatibility, but letting the under specification of C bitfields basically infect D. Its the tail wagging the dog. Or leaky implementation. If I have a D program that links a dll or static lib also written in D, they could have incompatible bitfield layouts.
>>
>> You could fix this by specifying the layout for D bitfields, and using extern(C) when compatibility with the relevant C compiler is required. D already does that for classes and functions...
>
> `extern(C)` does not affect the layout of anything, as far as I know. It only impacts name mangling and calling convention. Using it to change layout would be a new feature.
>
> When I worked on Derelict and BindBC, I would have loved to have had bitfields in D. And I would have expected them to line up with the associated C compiler out of the box, because that's what already happens with structs.

Apparently I'm an idiot who has no idea what he's talking about.

Sorry.

On Wednesday, 10 July 2024 at 06:47:44 UTC, Walter Bright wrote:
> On 7/9/2024 3:57 AM, claptrap wrote:
>> You have completely missed the point. Struct layout doesn't change, it's fixed, it doesn't depend on what C compiler is attached.
>
> I'm sorry to say, it does.
>
>
>> You could fix this by specifying the layout for D bitfields, and using extern(C) when compatibility with the relevant C compiler is required.
>
> I've posted in the other thread simple means to lay out portable bitfields. More language features are not required.

I actually replied to mike yesterday and admitted that I was wrong, (I looked at the spec, should have done that before opening my mouth) and that I was and idiot, not sure if it got moderated because I was rude to myself? Or maybe mike thought I was being sarcastic, not sure tbh.

But I was wrong, sorry.

On 7/9/2024 4:58 AM, Mike Parker wrote:
> `extern(C)` does not affect the layout of anything, as far as I know. It only impacts name mangling and calling convention. Using it to change layout would be a new feature.

There is a case where it does. A struct with no data members is zero size if extern(C), otherwise it is size 1. The size 1 comes from C++, which (correctly) decided that individual objects should have distinct addresses.

This does have the potential to be memory unsafe, and a struct with no data members should probably be rejected in @safe mode.

https://issues.dlang.org/show_bug.cgi?id=24657

On 7/10/2024 2:17 PM, claptrap wrote:
> I'm not selling penis enlargement products if that helps?

Please stop with the inappropriate comments.