Re: Since dmd 2.096.0: import `x.t` is used as a type
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
Re: Since dmd 2.096.0: import `x.t` is used as a type
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).
Re: Since dmd 2.096.0: import `x.t` is used as a type
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
Re: Since dmd 2.096.0: import `x.t` is used as a type
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
```
Re: Since dmd 2.096.0: import `x.t` is used as a type
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.
Re: Since dmd 2.096.0: import `x.t` is used as a type
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.
Re: Since dmd 2.096.0: import `x.t` is used as a type
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.
Re: Since dmd 2.096.0: import `x.t` is used as a type
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).
Re: Since dmd 2.096.0: import `x.t` is used as a type
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.
Since dmd 2.096.0: import `x.t` is used as a type
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;
...
```
