This fails:

module a.b.m;

int hello() {
   return 42;
}

extern (C) void main() {
   assert (a.b.m.hello() == 42);
}

Is it supposed to?

On Sunday, 15 November 2020 at 22:20:12 UTC, Dibyendu Majumdar wrote:
> This fails:
>
> module a.b.m;
>
> int hello() {
>    return 42;
> }
>
> extern (C) void main() {
>    assert (a.b.m.hello() == 42);
> }
>
> Is it supposed to?

Yes, the fully-qualified name of a module is not in scope unless you `static import` it.

There is one exception: you are always allowed to use a fully-qualified name on the right-hand side of an alias declaration. See <https://dlang.org/spec/declaration.html#alias>.

On 11/15/20 5:38 PM, Paul Backus wrote:
> On Sunday, 15 November 2020 at 22:20:12 UTC, Dibyendu Majumdar wrote:
>> This fails:
>>
>> module a.b.m;
>>
>> int hello() {
>>    return 42;
>> }
>>
>> extern (C) void main() {
>>    assert (a.b.m.hello() == 42);
>> }
>>
>> Is it supposed to?
> 
> Yes, the fully-qualified name of a module is not in scope unless you `static import` it.

This isn't true. you can import a module and still use the FQN:

import std.stdio;

std.stdio.writeln("bar"); // OK

Note, if the module name is a single identifier, you can use it.

This seems like a weird limitation based on the fact that the package isn't defined.

It was introduced when the imports were fixed, but I'm not sure this was intentional.

If I put the above code in, and use the wayback compiler machine at run.dlang.io:

Up to      2.070.2: Success and no output
2.071.2 to 2.078.1: Success with output: onlineapp.d(7): Deprecation: package a.b is not accessible here
2.079.1 to 2.083.1: Success with output: onlineapp.d(7): Deprecation: package `a.b` is not accessible here
2.084.1 to 2.086.1: Failure with output: onlineapp.d(7): Error: package `a.b` is not accessible here
Since      2.087.1: Failure with output: onlineapp.d(7): Error: undefined identifier `b` in package `a`, perhaps add `static import a.b;`

IMO, you should be able to access the package you are defined in.

-Steve

On Monday, 16 November 2020 at 13:07:21 UTC, Steven Schveighoffer wrote:
> On 11/15/20 5:38 PM, Paul Backus wrote:
>> On Sunday, 15 November 2020 at 22:20:12 UTC, Dibyendu Majumdar wrote:
>>> This fails:
>>>
>>> module a.b.m;
>>>
>>> int hello() {
>>>    return 42;
>>> }
>>>
>>> extern (C) void main() {
>>>    assert (a.b.m.hello() == 42);
>>> }
>>>
>>> Is it supposed to?
>> 
>
> This seems like a weird limitation based on the fact that the package isn't defined.
>
> IMO, you should be able to access the package you are defined in.
>

It didn't make sense to me - thank you for confirming.

Regards

On 11/16/2020 5:07 AM, Steven Schveighoffer wrote:
> [...]
Please post to bugzilla.

On Saturday, 21 November 2020 at 02:02:51 UTC, Walter Bright wrote:
> On 11/16/2020 5:07 AM, Steven Schveighoffer wrote:
>> [...]
> Please post to bugzilla.

https://issues.dlang.org/show_bug.cgi?id=21413

On Monday, 16 November 2020 at 13:07:21 UTC, Steven Schveighoffer wrote:
> import std.stdio;
>
> std.stdio.writeln("bar"); // OK

Is this expected?

void main ()
{
   {
      import std.stdio;
      std.stdio.writeln ("test"); // okay
   }
   {
      import std.stdio : writeln;
      std.stdio.writeln ("test"); // Error: undefined identifier std
   }
}

On Friday, 11 December 2020 at 01:34:13 UTC, kdevel wrote:
> Is this expected?

Yes, and this is kinda why I don't like using selective imports.

With a normal import, the module name is the only thing actually added to the scope. Everything in that module is found by walking the import chains after not finding it locally (unless you use `static import` which means it does not add it to the chain).

With a selective import, the only thing added is the specific name you did. The module name is NOT in scope and there is no chain established.

Selective imports are more like making an alias than other imports.

On Friday, 11 December 2020 at 01:34:13 UTC, kdevel wrote:
> On Monday, 16 November 2020 at 13:07:21 UTC, Steven Schveighoffer wrote:
>> import std.stdio;
>>
>> std.stdio.writeln("bar"); // OK
>
> Is this expected?
>
> void main ()
> {
>    {
>       import std.stdio;
>       std.stdio.writeln ("test"); // okay
>    }
>    {
>       import std.stdio : writeln;
>       std.stdio.writeln ("test"); // Error: undefined identifier std
>    }
> }

This behaviour makes sense to me...you've explicitly exposed only that symbol.

On Friday, 11 December 2020 at 01:38:44 UTC, Adam D. Ruppe wrote:

[...]

> With a normal import, the module name is the only thing actually added to the scope. Everything in that module is found by walking the import chains after not finding it locally (unless you use `static import` which means it does not add it to the chain).

Just 'implemented' the following bug:

~~~
import std.conv;

class B {
}

class D : B {
   string text;
}

void main ()
{
   B b = new D;
   string s = b.text;
}
~~~

Due to UFCS std.conv.text grabs the object. Only a `static import`
or a selective import would reveal the problem during compile time.