The forked elephant in the room

[Jonathan M Davis]

On Thursday, February 1, 2024 10:49:42 AM MST Walter Bright via Digitalmars-d 
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.
>
> 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.

Well, I would point out that if import C had its own syntax, anyone who
wanted it to be invisible as to whether importC was involved or not could
just stick the importC import inside of another module and make the importC
import public. Then code could import the D module without knowing or caring
whether importC was involved or not - and when someone did want to make it
clear that that's what's going on, they could just use the importC import
directly.

While I agree that you often don't want to have to care about which language
defines something, prior to importC, you could at least rely on the fact
that what you were importing was D code even if they were just declarations.
And it's certainly my gut reaction that I very much want to know when I'm
importing C code and not D code. Whether the module being imported is
actually a D module or a C file changes what I have to look for when looking
up the file to see what's in it, and hiding the fact that it's a C file just
makes that harder. And in general, I want to know when stuff is extern(C),
or extern(C++), or extern(D), or whatever because that does affect how it
should be used.

So, personally, I'm inclined to think that making importC imports distinct
from normal D imports would reduce the number of problems involved rather
than increase them, but it's also true that I haven't done anything with
importC yet (the one time I tried, I couldn't figure out how to do it in the
time that I had). So, I haven't had to actually deal with the pros or cons
of how it currently works.

- Jonathan M Davis