Thread overview
Since dmd 2.096.0: import `x.t` is used as a type
Apr 30
kdevel
Apr 30
user1234
Apr 30
kdevel
6 days ago
Basile B.
5 days ago
kdevel
5 days ago
Basile B.
5 days ago
kdevel
4 days ago
jmh530
April 30

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;
...
April 30

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

>

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

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

April 30

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

6 days ago

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.

5 days ago

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.

5 days ago

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

>

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

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

5 days ago

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

>

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

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
5 days ago
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
4 days ago

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 si I guess you're stuck with the author answer, 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).

4 days ago
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