On Tuesday, 28 September 2021 at 23:54:52 UTC, Walter Bright wrote:
>
> Of course that will fail, just like it will fail if you compile code with TinyCC's stdlib and link with clang's stdlib.

I now realize that using D, it was "just working" because of work that went into DRuntime to avoid ABI problems:
https://github.com/dlang/druntime/blob/a17bb23b418405e1ce8e4a317651039758013f39/src/core/sys/posix/dirent.d#L53

So the current state is that: the D compiler works will all (supported) C runtime, with a single set of D headers.

This won't be the case in an ImportC future, your build will depend on pointing on the right libc include paths (unless there is a similar syncretic header set that works with common libc), and I just hope the compiler will do it automatically :)

On Tuesday, 28 September 2021 at 23:16:28 UTC, Walter Bright wrote:
>
> Anyhow, pointing out non-standard constructs that can be replaced with standard ones


But _Alignas strictly can't replace #pragma pack.

D's align(), C's _Alignas, and #pragma pack have 3 different semantics.

See https://ideone.com/bv6mET

- #pragma pack can only _reduce_ alignment requirements within a struct, NOT introduce additional padding

- _Alignas, contrarily, can only be used to _increase_ alignment and introduce padding, but cannot reduce the natural alignment of a field.

- D's align can both reduce and increase field alignment, which is of course the better option (https://ideone.com/TLSZUO)

On 9/28/2021 5:11 PM, Guillaume Piolat wrote:
> This won't be the case in an ImportC future, your build will depend on pointing on the right libc include paths (unless there is a similar syncretic header set that works with common libc), and I just hope the compiler will do it automatically :)

I'm afraid that in order for D to save you, you have to write the code in D, not C!

On 9/28/2021 5:46 PM, Guillaume Piolat wrote:
> On Tuesday, 28 September 2021 at 23:16:28 UTC, Walter Bright wrote:
>>
>> Anyhow, pointing out non-standard constructs that can be replaced with standard ones
> 
> 
> But _Alignas strictly can't replace #pragma pack.
> 
> D's align(), C's _Alignas, and #pragma pack have 3 different semantics.
> 
> See https://ideone.com/bv6mET
> 
> - #pragma pack can only _reduce_ alignment requirements within a struct, NOT introduce additional padding
> 
> - _Alignas, contrarily, can only be used to _increase_ alignment and introduce padding, but cannot reduce the natural alignment of a field.
> 
> - D's align can both reduce and increase field alignment, which is of course the better option (https://ideone.com/TLSZUO)
> 
> 

C11 6.7.5-4 sez: "The combined effect of all alignment attributes in a declaration shall not specify an alignment that is less strict than the alignment that would otherwise be required for the type of the object or member being declared."

Which I interpret to mean it can be allowed as an extension.

On Tuesday, 28 September 2021 at 06:05:04 UTC, Walter Bright wrote:
> https://issues.dlang.org/show_bug.cgi?id=22315
>
> I'm on the fence about implementing this. On the one hand, I can do it and make it work. On the other hand, the C11 way is to use _Alignas, and that's 10 years old now. How far do we go with implementing all the nutburger obsolete C extension cruft out there?

My vote is for supporting it. That way it will be complete, and I remember seeing it around networking and serialization contexts for example. I tried asking in some c/c++ forums and got an estimate at around 3-5% of stuff use it according to them. Not much, but also not below 1%.

On Tuesday, 28 September 2021 at 06:05:04 UTC, Walter Bright wrote:
> https://issues.dlang.org/show_bug.cgi?id=22315
>
> I'm on the fence about implementing this. On the one hand, I can do it and make it work. On the other hand, the C11 way is to use _Alignas, and that's 10 years old now. How far do we go with implementing all the nutburger obsolete C extension cruft out there?



 I believe I know why you are on the fence about it, and I feel the same.
My concept would be simply to make D its own language, the more unneccessary  stuff
is added the more complicated and disorienting it can be to users.

My point of view is, so long as the compiler can use C code with all its features then
there is no point in making a D version of the features that aren't important.

Simplicity is beautiful.

Thank you

On Tuesday, 28 September 2021 at 06:05:04 UTC, Walter Bright wrote:
> https://issues.dlang.org/show_bug.cgi?id=22315
>
> I'm on the fence about implementing this. On the one hand, I can do it and make it work. On the other hand, the C11 way is to use _Alignas, and that's 10 years old now. How far do we go with implementing all the nutburger obsolete C extension cruft out there?

I have to add to my message.

   If D is not a superset of C then there's no need for "compatibility".
There are already enough underlying differences in syntax that D is not truly
"compatible" with C.  You could make D a typechecked Python with little similarities
in syntax and still say it is compatible.

So long as it can be translated to C and that it can build symbol tables of C, for
typing, then it would still have all the same usability as "betterC".

I think the issue that happened with C++ was that it was made a superset and then
they just kept adding features, shortcuts, whatnot. The syntax can be very confusing, there are redundant syntax constructs, shortcuts, and structurally it doesn't look organized.

On 9/29/2021 1:21 PM, Steven Schveighoffer wrote:
> Might I suggest -- you are going to have to preprocess the file anyway. If you filter the preprocessor results through another processor that "fixes" these things (like changes #pragma pack into D `align` directives), then you have room to deal with nutburgers.

It's not the implementation difficulty, it's more the opening of "support every extension every C compiler ever added" kind of thing.

Besides, the #pragma pack is never properly documented. For example,

    struct S
    #pragma pack(1)
    { ...
    #pragma pack()
      ...
    };

supposed to do? It wretchedly mixes up the preprocessor and the core language syntax in a completely undocumented manner (and they're supposed to be separate languages).