In article <de04ab$b14$1@digitaldaemon.com>, Ben Hinkle says...
> Should the imported
>symbols only be visible after the executed statement or throughout the scope body? . Also given that imports inside classes and structs are discouraged (and undocumented I believe) by Walter

Why do you say that?

"The top level scope in the module is merged with the current scope." from http://www.digitalmars.com//d/index.html

I see no limitation on "current scope", but I remember a compiler message about the scope of the import declaration.

Ant

Hi,

>> Hi,
>> What about arbitrarily nested import statements?
>> Seems more useful than a special case for unittest.
>> --AJG.
>
>Yeah - I'm worried about what it actually means, though. Should the imported symbols only be visible after the executed statement or throughout the scope body? .

I'm not saying I know "the" answer to this one, nor is this a feature I'm desperate about, but to me it would mean something like the following:

~Foo.d:
# mFooSymbol; // ERROR.
# mBarSymbol; // ERROR.
# mBazSymbol; // ERROR.
#
# import mFoo;
# mFooSymbol; // OK.
# mBarSymbol; // ERROR.
# mBazSymbol; // ERROR.
#
# class Bar {
#     mFooSymbol; // OK.
#     mBarSymbol; // ERROR.
#     mBazSymbol; // ERROR.
#
#     import mBar;
#     mFooSymbol; // OK.
#     mBarSymbol; // OK.
#     mBazSymbol; // ERROR.
#
#     void Baz() {
#          mFooSymbol; // OK.
#          mBarSymbol; // OK.
#          mBazSymbol; // ERROR.
#
#         import mBaz;
#         mFooSymbol; // OK.
#         mBarSymbol; // OK.
#         mBazSymbol; // OK.
#     }
#
#     mFooSymbol; // OK.
#     mBarSymbol; // OK.
#     mBazSymbol; // ERROR.
# }
#
# mFooSymbol; // OK.
# mBarSymbol; // ERROR.
# mBazSymbol; // ERROR.

Don't know if I missed any cases in there.

>Also given that imports inside classes and structs are discouraged (and undocumented I believe) by Walter I'd imagine that putting them inside functions will be even more hairy.

Do you mean semantically or in terms of the compiler's own implementation?

Cheers,
--AJG.

"Ant" <Ant_member@pathlink.com> wrote in message news:de050d$blb$1@digitaldaemon.com...
> In article <de04ab$b14$1@digitaldaemon.com>, Ben Hinkle says...
>> Should the imported
>>symbols only be visible after the executed statement or throughout the
>>scope
>>body? . Also given that imports inside classes and structs are discouraged
>>(and undocumented I believe) by Walter
>
> Why do you say that?
>
> "The top level scope in the module is merged with the current scope." from http://www.digitalmars.com//d/index.html
>
> I see no limitation on "current scope", but I remember a compiler message about the scope of the import declaration.
>
> Ant

That sentance appears in the 'module' page. No mention of importing other than at the top level of a module is made in the D docs (from what I could tell). The production DeclDefs in module.html is the only place I could find imports explicitly listed in the "grammar" such as it is. For example the next section "Scope and Modules" only talks about importing a module into another module. The classes.html doc doesn't talk about importing or what it means (in general the classes.html never seems to actually say what's allowed inside a class body). If one interprets "current scope" as really meaning any scope then it would also include function scopes - which currently doesn't work. So I think attaching too much meaning to the words "current scope" is dangerous - the web pages are .. umm... informal.

I also briefly tried searching for a post I recall where he suggested people avoid importing inside class bodies even though it technically works (depending on bugs, I think). None of the threads with the obvious subject names had anything useful and it's impossible to search those long meandering threads with generic subjects. I know several people argued strongly that they try to import inside classes as much as possible so it's a touchy subject.

On Wed, 17 Aug 2005 16:47:54 -0400, Ben Hinkle wrote:


[snip]

> No mention of importing other than at the top level of a module is made in the D docs (from what I could tell). The production DeclDefs in module.html is the only place I could find imports explicitly listed in the "grammar" such as it is ...

Backing up a little ... it would be useful if Walter could provide an easy-to-use mechanism so that specific imports only occurred during unit testing.

-- 
Derek Parnell
Melbourne, Australia
18/08/2005 6:56:15 AM

"AJG" <AJG_member@pathlink.com> wrote in message news:de069s$cpb$1@digitaldaemon.com...
> Hi,
>
>>> Hi,
>>> What about arbitrarily nested import statements?
>>> Seems more useful than a special case for unittest.
>>> --AJG.
>>
>>Yeah - I'm worried about what it actually means, though. Should the
>>imported
>>symbols only be visible after the executed statement or throughout the
>>scope
>>body? .
>
> I'm not saying I know "the" answer to this one, nor is this a feature I'm desperate about, but to me it would mean something like the following:
>
> ~Foo.d:
> # mFooSymbol; // ERROR.
> # mBarSymbol; // ERROR.
> # mBazSymbol; // ERROR.
> #
> # import mFoo;
> # mFooSymbol; // OK.
> # mBarSymbol; // ERROR.
> # mBazSymbol; // ERROR.

This part so far is different than D today. mFooSymbol is available in the first line.

> # class Bar {
> #     mFooSymbol; // OK.
> #     mBarSymbol; // ERROR.
> #     mBazSymbol; // ERROR.
> #
> #     import mBar;
> #     mFooSymbol; // OK.
> #     mBarSymbol; // OK.
> #     mBazSymbol; // ERROR.

This is different, too.

> #     void Baz() {
> #          mFooSymbol; // OK.
> #          mBarSymbol; // OK.
> #          mBazSymbol; // ERROR.
> #
> #         import mBaz;
> #         mFooSymbol; // OK.
> #         mBarSymbol; // OK.
> #         mBazSymbol; // OK.
> #     }
> #
> #     mFooSymbol; // OK.
> #     mBarSymbol; // OK.
> #     mBazSymbol; // ERROR.
> # }
> #
> # mFooSymbol; // OK.
> # mBarSymbol; // ERROR.
> # mBazSymbol; // ERROR.
>
> Don't know if I missed any cases in there.
>
>>Also given that imports inside classes and structs are discouraged
>>(and undocumented I believe) by Walter I'd imagine that putting them
>>inside
>>functions will be even more hairy.
>
> Do you mean semantically or in terms of the compiler's own implementation?
>
> Cheers,
> --AJG.
>

Personally if putting restrictions on the places where imports are allowed helps make compilers simpler and less buggy (eg Java forces all imports at the top) then I'm all for it. The current documentation on imports is very vague.

"Derek Parnell" <derek@psych.ward> wrote in message news:1jg0ds14poumr.gmvd6saz5sez$.dlg@40tude.net...
> On Wed, 17 Aug 2005 16:47:54 -0400, Ben Hinkle wrote:
>
>
> [snip]
>
>> No mention of importing other than at the top level of a module is made
>> in
>> the D docs (from what I could tell). The production DeclDefs in
>> module.html
>> is the only place I could find imports explicitly listed in the "grammar"
>> such as it is ...
>
> Backing up a little ... it would be useful if Walter could provide an easy-to-use mechanism so that specific imports only occurred during unit testing.
>
> -- 
> Derek Parnell
> Melbourne, Australia
> 18/08/2005 6:56:15 AM

ok - that's the point of this thread. Was there some confusion I missed? AJG was generalizing the original proposal.

"Victor Nakoryakov" <nail-mail@mail.ru> wrote in message news:ddv03k$2aug$1@digitaldaemon.com...
> Hi all.
>
> Is there any reason for forbiding import statements inside unittests?
> I often want import some module just for testing purposes only and do not
> want keep this dependency in release builds.
>
> -- 
> Victor (aka nail) Nakoryakov
> nail-mail<at>mail<dot>ru
>
> Krasnoznamensk, Moscow, Russia

Actually now that I think about it why is "private import" inadequate? A private import should have no effect on modules that import the original module.