On 5/16/2023 12:48 AM, Patrick Schluter wrote:
> On Monday, 15 May 2023 at 20:19:05 UTC, IGotD- wrote:
>> On Sunday, 14 May 2023 at 23:56:55 UTC, Walter Bright wrote:
>>>
>>> There are a number of C features which do not translate into D. But with ImportC I can make them work seamlessly.
>>
>> What are the C features that cannot be expressed in D?
> 
> VLA's and flexible arrays.

Some more things:

1. struct tags and non-tag names co-existing in the same scope

2. enum member names get "promoted" to the surrounding scope, losing their enum-ness

3. bit fields (since fixed by adding bitfields to D!)

4. C's everything-in-one-global-namespace issue

5. default initialization isn't always zero in D

6. different rules for `const` (ImportC admittedly fakes it)


If you look at the frontend source code, the semantic routines have lots of "if it's C do this instead".

Of course, "cannot" is an absolute word. There are always ways to make something work, but the result may be just too ugly or otherwise unpalatable. With ImportC, we just let C be C instead of trying to bash it into D code.

On 5/16/2023 6:36 AM, Adam D Ruppe wrote:
> ImportC can do C bitfields, but since they're layout is undefined it is useless anyway.

Pedantically, the C layout is not undefined, it is implementation defined. D's bitfields, however, are defined to match the layout of the associated C compiler.

But as a practical matter, if you stick with `int` and `unsigned` bit field types, the layout is consistent across compilers with 32 bit ints. Any other differences would only be a problem if data is moved between systems. The C code will still work.

It's analogous to the size of `int` being implementation defined, along with the size of `char`, `long`, `long long`, the signedness of char being implementation defined, whether it's ones or twos complement, and so on. But C remained useful.

mportC also implements a number of half-specified associated C compiler extensions, because (sadly) nearly all of the C header files unnecessarily rely on these extensions.

Ironically, by making D bitfields match the associated C compiler's, it arguably makes D bitfields *more* portable.


> (Walter also copied importC's awful bitfields into D, but I hope that mistake is reverted.)

There's always https://dlang.org/phobos/std_bitmanip.html#bitfields which do have a portable defined format.

Note that nobody has implemented in Phobos a bitfield setup that matches the associated C compiler's bit fields, making such C constructs difficult to access from D. They're easy now!

On Wednesday, 17 May 2023 at 03:52:33 UTC, Walter Bright wrote:
> On 5/16/2023 6:36 AM, Adam D Ruppe wrote:
>> ImportC can do C bitfields, but since they're layout is undefined it is useless anyway.
>
>
> Ironically, by making D bitfields match the associated C compiler's, it arguably makes D bitfields *more* portable.
>
>

I agree 100%. Usually unhappy users are more vokal than happy users, so I just wanted to say thanks Walter, I for one love this feature!

On Wednesday, 17 May 2023 at 03:52:33 UTC, Walter Bright wrote:
> On 5/16/2023 6:36 AM, Adam D Ruppe wrote:
>> ImportC can do C bitfields, but since they're layout is undefined it is useless anyway.
>
> Pedantically, the C layout is not undefined, it is implementation defined. D's bitfields, however, are defined to match the layout of the associated C compiler.

This is what makes them a major footgun. Other than being underpowered for the complexity they add (I want the compiler to help me do discontinuous bitpacking not just easy stuff), you can't rely on the layout for basically anything other than space-efficiency, so you can't guarantee something will actually round-trip (say) over the network or even a filesystem/buffer on the same computer.

This, for example, is why one of the ELF specifications explicitly recommends not using bitfields to implement it.

On Wednesday, 17 May 2023 at 03:52:33 UTC, Walter Bright wrote:
> On 5/16/2023 6:36 AM, Adam D Ruppe wrote:
>> ImportC can do C bitfields, but since they're layout is undefined it is useless anyway.
>
> Pedantically, the C layout is not undefined, it is implementation defined. D's bitfields, however, are defined to match the layout of the associated C compiler.

What defines the "associated C compiler"?
It's the first time I hear it for D.

thanks,
  Johan

On 5/17/2023 2:53 AM, max haughton wrote:
> This, for example, is why one of the ELF specifications explicitly recommends not using bitfields to implement it.

That's also why people implementing ELF use typedefs instead of ints, etc., and have special code to deal with endianness, which is also implementation defined.

Despite all this implementation defined behavior in C, there are some things that while pedantically implementation defined, are in practice consistently defined across diverse compilers. The int bitfields, for example.

On 5/17/2023 4:25 AM, Johan wrote:
> What defines the "associated C compiler"?

The D implementation.

> It's the first time I hear it for D.

It's referred to in the D spec.

https://dlang.org/glossary.html#acc

On Wednesday, 24 May 2023 at 14:28:52 UTC, Quirin Schroll wrote:
> Yes, the syntax is awful. It should have been `__vector(bool[n])`:

How would that interact with things like `sign.sizeof`?

I wrote about some of these things in more detail here btw:

http://dpldocs.info/this-week-in-d/Blog.Posted_2022_09_12.html#bitfields