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