Thread overview
[Issue 22674] ImportC: compatible types declared in different translation units are not treated equivalent in D.
May 16
mhh
May 16
Susan
January 14
https://issues.dlang.org/show_bug.cgi?id=22674

[email protected] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ImportC

--
January 22
https://issues.dlang.org/show_bug.cgi?id=22674

Walter Bright <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |[email protected]
         Resolution|---                         |WONTFIX

--- Comment #1 from Walter Bright <[email protected]> ---
I looked into making an adjustment to the compiler, which would be regarding types in C imports with the same name be the same type. Unfortunately, the D compiler is designed around types are the same if they have the same address. Changing this would be very difficult, and would impair speed even if it never actually happens.

But there is a solution. Accessing things from D can be qualified, so:

  import maker;
  import freer;

  void do_foo(){
    auto f = cast(freer.FooRef)make_foo();
    free_foo(f);
  }

Doing this in ImportC is slightly trickier, as C doesn't have name qualification:

  __import maker;
  __import freer : FooRef;

  void do_foo(){
    FooRef f = (FooRef)make_foo();
    free_foo(f);
  }

Once could go further by creating a D file that merges the duplicate declarations:

  import maker;
  import freer;

  alias FooRef = maker.FooRef;
  extern (C) void free_foo(FooRef foo);

and then importing that module. This works because the declaration of free_foo() will link without problems with the definition of free_foo() where ever it may be, as C name mangling does not mangle in the types. This merged D file may be imported either by D code or ImportC code.

Hence, I'm going to mark this as WONTFIX because it is too disruptive, and accommodations are available that aren't too bad.

--
May 16
https://issues.dlang.org/show_bug.cgi?id=22674

[email protected] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #2 from [email protected] ---
If the goal is to have seamless C importing where you can just import c headers and the compiler even runs the preprocessor for you, I can’t see how this is an acceptable outcome. Even basic thing’s like stdio’s FILE* fall victim to this bug.

--
May 16
https://issues.dlang.org/show_bug.cgi?id=22674

Adam D. Ruppe <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]

--
May 16
https://issues.dlang.org/show_bug.cgi?id=22674

--- Comment #3 from Adam D. Ruppe <[email protected]> ---
i wanna subscribe to this too as i also wrote about it:

http://dpldocs.info/this-week-in-d/Blog.Posted_2022_05_16.html#importc-and-module-namespaces


Working on isolated unittests and one day toys is one thing. Working in a real world project that has more than one piece is another.

My proposal there is to bring the importC declarations into a global implementation-defined module, then the other names work like `mixin templates` or `aliases` for disambiguation purposes.

--
May 16
https://issues.dlang.org/show_bug.cgi?id=22674

mhh <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]
           Severity|normal                      |major

--- Comment #4 from mhh <[email protected]> ---
This bug is an important canary for ImportC be anything other than toy.

Note that resolving this issue may not be a fix for this particular bug but rather completely reframing how C code works.

--
May 16
https://issues.dlang.org/show_bug.cgi?id=22674

Susan <su+dla[email protected]angel-island.zone> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]
                   |                            |.zone

--
July 30
https://issues.dlang.org/show_bug.cgi?id=22674

--- Comment #5 from [email protected] ---
C23 has actually changed the rules and even allows compatible redeclaration of types *within* a translation unit to be treated as the same.

--