www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Since dmd 2.096.0: import `x.t` is used as a type

reply kdevel <kdevel vogtner.de> writes:
dmd since 2.096.0 with ``t.d``

```t.d
module t;

class t {
}
```

and ``x.d``

```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:

```x.d
...
import t : t;
...
```
Apr 30 2021
parent reply user1234 <user1234 12.de> writes:
On Friday, 30 April 2021 at 17:58:43 UTC, kdevel wrote:

 dmd since 2.096.0 with ``t.d``

 ```t.d
 module t;

 class t {
 }
 ```

 and ``x.d``

 ```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:

 ```x.d
 ...
 import t : t;
 ...
 ```


Likely a side effect of https://github.com/dlang/dmd/pull/12178 
but
according to me the new behavior is correct.
Apr 30 2021
parent reply kdevel <kdevel vogtner.de> writes:
On Friday, 30 April 2021 at 19:17:14 UTC, user1234 wrote:
[...]

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


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).
Apr 30 2021
parent reply Basile B. <b2.temp gmx.com> writes:
On Friday, 30 April 2021 at 21:41:43 UTC, kdevel wrote:

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

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


 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).


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.
May 01 2021
parent reply kdevel <kdevel vogtner.de> writes:
On Saturday, 1 May 2021 at 16:32:32 UTC, Basile B. wrote:

 Hard breakage is not acceptable, even if the goal is to 
 introduce a more correct behavior.


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.
May 02 2021
parent reply Basile B. <b2.temp gmx.com> writes:
On Sunday, 2 May 2021 at 15:41:13 UTC, kdevel wrote:

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

 Hard breakage is not acceptable, even if the goal is to 
 introduce a more correct behavior.


 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?


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](https://github.com/dlang/dmd/pull/12178#issuecomment-773886263) si
I guess you're stuck with [the author
answer](https://github.com/dlang/dmd/pull/12178#issuecomment-773902749), 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.


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


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

```styx
§s.sx
unit s;

§u.sx
unit v;

struct s {}

import s;

var s s1;
```

gives


 u.sx:8:8: error, symbol `s` already declared line 6


same when the import and the var decls positions are exchanged.
May 02 2021
next sibling parent reply kdevel <kdevel vogtner.de> writes:
On Sunday, 2 May 2021 at 18:36:25 UTC, Basile B. wrote:
[...]

 BTW during the PR review the problem you encounter [was 
 anticipated](https://github.com/dlang/dmd/pull/12178#issuecomment-773886263)
si I guess you're stuck with [the author
answer](https://github.com/dlang/dmd/pull/12178#issuecomment-773902749), i.e
"this worked because of a special case".


Sure.


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


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
```
May 02 2021
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/2/21 4:32 PM, kdevel wrote:

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

 BTW during the PR review the problem you encounter [was 
 anticipated](https://github.com/dlang/dmd/pull/12178#issuecomment-773886263) 
 si I guess you're stuck with [the author 
 answer](https://github.com/dlang/dmd/pull/12178#issuecomment-773902749), 
 i.e "this worked because of a special case".


 
 Sure.
 

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


 
 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
 ```


In order for that to work, you need to pass the file that contains the 
module to the compiler.

Otherwise, the compiler must assume that the module lives in the file 
named after itself.

-Steve
May 02 2021
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Sunday, 2 May 2021 at 18:36:25 UTC, Basile B. wrote:

 [snip]

 BTW during the PR review the problem you encounter [was 
 anticipated](https://github.com/dlang/dmd/pull/12178#issuecomment-773886263)
si I guess you're stuck with [the author
answer](https://github.com/dlang/dmd/pull/12178#issuecomment-773902749), i.e
"this worked because of a special case".
[snip]


"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).
May 03 2021
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/3/21 11:04 AM, jmh530 wrote:

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

 [snip]

 BTW during the PR review the problem you encounter [was 
 anticipated](https://github.com/dlang/dmd/pull/12178#issuecomment-773886263) 
 si I guess you're stuck with [the author 
 answer](https://github.com/dlang/dmd/pull/12178#issuecomment-773902749), 
 i.e "this worked because of a special case".
 [snip]


 
 "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).


Yeah, I think the situation with top-level modules and package names is 
kind of an elephant in the room. If you have any packages which have 
top-level modules, you have lots of weird corner cases (even before this 
change) that make things difficult.

IMO, we should address this at a design level. What that means, I'm not 
sure. At any point alias is going to throw a monkey wrench into anything 
we could come up with. But it should be at least possible to keep 
existing code compiling.

-Steve
May 03 2021