On 10/20/21 10:40 AM, Mathias LANG wrote:

Yes, but it's more of a garden variety naming conflict that can happen in any ecosystem. Not the same as the weird status of top-level module or package names in D.

-Steve

On Wednesday, 20 October 2021 at 13:39:22 UTC, Steven Schveighoffer wrote:

Huh. Yep, it sure does:

import std.stdio;

// Error: variable `onlineapp.std` conflicts with import `onlineapp.std` at onlineapp.d(1)
int std;

void main()
{
    writeln("Hello world!");
}

Honestly I would classify this as a straight-up bug. According to the spec on Symbol Name Lookups, this program should work fine.

On Tuesday, 19 October 2021 at 15:15:29 UTC, newbie wrote:

Hi Mathias LANG,

It has been 6 month since latest alpine LDC release, and now alpine LLVM already upgrade to LLVM12. I hope there is any plan or roadmap to share with community.

On Wednesday, 27 October 2021 at 06:30:43 UTC, newbie wrote:

LDC v1.28.0 just hit edge today and will be part of 3.15.
Dub and rdmd have been rebuilt too. Currently working on DMD.

On Thursday, 28 October 2021 at 09:18:51 UTC, Mathias LANG wrote:

Thanks for the great work, now I am able to remove a lot workaround to keep backward compatible.

On Tuesday, 19 October 2021 at 04:03:38 UTC, Mathias LANG wrote:

import std.stdio;

void main ()
{
    writeln(foo.stringof);
}

This is ultimately because D modules just reuse the notion of import paths from C. I had to find a better way in my language in order to handle self-rebuilds, where there's name collisions between compiler runtime and compiled runtime packages, but the same approach would also solve the issue in D, so let me outline it.

Basically, we replace import paths (-I~/.dub/packages/bla/src) with package paths:

-Pbla:~/.dub/packages/bla/src

As you can see, each package is named. This allows us to explicitly specify which packages a package can see and access:

-Pmain:src:bla,bla2

As it walks imports, the compiler tracks each module's package. When evaluating an import statement, only files in the current package or a direct dependency of the current package are considered.

Thus, your 'foo' problem will only happen if you directly depend on package "foo" in your dub.json.

This approach is fully backwards compatible with include paths. It also allows other funky things, such as per-package settings (-i, -deps, -g, -debug etc) which solves a whole host of problems with dub. For instance, a static library can safely be used, even if the main program's source is being built with different flags.