dmd since 2.096.0 with t.d

module t;

class t {
}

and x.d

module x;
import t;

void main ()
{
   t x = new t;
}

reports

$ dmd -i x.d
x.d(6): Error: import `x.t` is used as a type
x.d(6): Error: import `x.t` is used as a type

Could not find this Change in https://dlang.org/changelog/2.096.0.html. Has this been "fixed" with some other issue?

Workaround:

...
import t : t;
...

On Friday, 30 April 2021 at 17:58:43 UTC, kdevel wrote:

module t;

class t {
}

module x;
import t;

void main ()
{
   t x = new t;
}

$ dmd -i x.d
x.d(6): Error: import `x.t` is used as a type
x.d(6): Error: import `x.t` is used as a type

...
import t : t;
...

Likely a side effect of https://github.com/dlang/dmd/pull/12178 but
according to me the new behavior is correct.

On Friday, 30 April 2021 at 19:17:14 UTC, user1234 wrote:
[...]

It breaks my code. I have files named $C containing struct or class $C plus some other stuff. Using the workaround means to switch to selective imports for all used types/functions within this module.

Found another workaround: I created a symlink here -> . and replaced all imports $C with here.$C. In some places I had to remove an artificial "prefix" ($C.$C -> $C).

On Friday, 30 April 2021 at 21:41:43 UTC, kdevel wrote:

I understand the situation but I can opnly suggest to fill a report.
Hard breakage is not acceptable, even if the goal is to introduce a more correct behavior.

On Saturday, 1 May 2021 at 16:32:32 UTC, Basile B. wrote:

I still wonder why module names are taken as a candidates for types and functions in the first place. Isn't there a symbol table for module names separate from that for type and function names?

Just checked how things are done in another language where modules are called “packages”:

// Foo.go
package Foo
import "fmt"

func Foo () {
   fmt.Println ("this is Foo.Foo ()");
}

// Soo.go
package Soo

type Soo struct {
   Name string
}

// main.go
package main
import "fmt"
import . "Foo"
import . "Soo"

func main () {
   fmt.Println ("main package")
   Foo ()
   s := Soo {Name: "xx"}
   fmt.Println (s.Name)
}

Besides the hard to remember syntax that only those symbols are exported which start with an uppercase letter it works as expected.

On Sunday, 2 May 2021 at 15:41:13 UTC, kdevel wrote:

I dont think so. That would lead to special cases in fully qualified lookups.
Lookups must follow the reverse lexical order of declarations so an import adds a symbols in the current scope.

BTW during the PR review the problem you encounter was anticipated si I guess you're stuck with the author answer, i.e "this worked because of a special case".

Again you can still try to get the change turn into a deprecation first, that'd be legit.

I have checked in styx too. This does not work either but for another reason that D, that is that overloads are explicit, meaning all names unique in a given scope, so

§s.sx
unit s;

§u.sx
unit v;

struct s {}

import s;

var s s1;

gives

same when the import and the var decls positions are exchanged.

On Sunday, 2 May 2021 at 18:36:25 UTC, Basile B. wrote:
[...]

Sure.

It only broke the compilation which I already have fixed. Kind of. I would have filed a bug if the runtime went kaput.

After reading https://dlang.org/spec/module.html#module_declaration again I wonder why there is no advice to avoid module (file) names which equate symbol names defined in the module. I also wonder how I get a module file named foo-bar.d referenced from another module. Following the advice in the documentation

// foo-bar.d
module foo_bar;

void foo ()
{
}

// main.d
import foo_bar;

void main ()
{
   foo;
}

it does not compile:

$ dmd -i main.d
main.d(1): Error: module `foo_bar` is in file 'foo_bar.d' which cannot be read

On Sunday, 2 May 2021 at 18:36:25 UTC, Basile B. wrote:

"this worked because of a special case" or "I'm sure they won't mind a bit of change" are not exactly the most fulfilling arguments to me. Don't we have transition switches for a reason?

The other solution is to keep the special case and then add additional logic to handle when the thing being looked up is not public (or whatever).