The forked elephant in the room

[Steven Schveighoffer]

On Thursday, 1 February 2024 at 17:49:42 UTC, Walter Bright wrote:
> On 1/31/2024 1:22 PM, Steven Schveighoffer wrote:
>> I also think the syntax can be clean without being ambiguous:
>> 
>> ```d
>> // import(C) soundio; // sadly not available because import 
>> expressions
>> import!C soundio;
>> ```
>
>
> The rationale for not having a special syntax for importing C 
> files is the importer should not have to know what language the 
> import comes from. That information should not "leak" into the 
> importer's code. The point is seamless integration.
>
> Analogously, if one gets from a .di file import:
>
> ```
> int foo();
> ```
>
> it should not matter what language foo() is implemented in. The 
> caller should not need to know. Having to organize the file 
> names and paths so this works is a very small price to pay for 
> this abstraction.

This means you are changing the language based on the environment 
and on the whims of the compiler implementer. It's not a small 
price when it happens. In an ideal situation, where you control 
all files and environmental conditions, it could be fine. But we 
all live in the real world.

>
> Besides, if you have these files in your folder:
>
> foo.c
>
> foo.d
>
> what is the maintainer looking at the files going to think? 
> Which one is incorporated into the code? foo.c? foo.d? both? 
> neither? It's a sloppy practice, not some vital thing to 
> support. One can name files as one pleases, organize them into 
> sensible folders, etc., all part of doing a good job as a 
> programmer.

In my case, it was:

raylib/rtextures.c

source/raylib/rtextures.d

And because D always looks in the current directory first, 
importing `raylib.rtextures` means the C file even though it 
wasn't intended to be part of the source code.

What was I intending? Not to have the C files participate at all, 
after all, they aren't in the source directory. My solution is to 
rename the C-containing folder to `raylibc` (which still could 
technically be imported, but I'm not sure how to fix that).

https://github.com/schveiguy/draylib/commit/9b04409fc3bda331d0a03583b2861552ffcaab04

In the general case, there are easily situations where C files 
might be in places that you need to specify an import path, where 
you *only* want one C file, but other C files that you *don't* 
want happen to conflict import-wise with D files in completely 
unrelated directories. It's not just the obviously wrong 
situation of putting a C and D file in the same directory.

D has this problem even with other D files. This is why I always 
recommend putting all your library files into a uniquely-named 
package. But with C files it's even worse, because C environments 
are not constructed with the import rules of D in mind.

-Steve