On 12/06/2011 22:15, Walter Bright wrote:
> Nobody seems to have noticed yet, but yesterday I removed the
> restriction preventing import declarations from being used in functions.
> These now work:
>
> void test1()
> {
> import std.c.stdio;
> printf("hello world\n");
> }
>
> void test2()
> {
> static import std.c.stdio;
> std.c.stdio.printf("hello world\n");
> }
>
> https://github.com/D-Programming-Language/dmd/commit/d5fbd53aa8d8452dce2514944575e654d387477a
>
>
> I believe this can lead to better encapsulation of code, especially when
> using mixins, versioning and other conditional compilation constructs.

I did notice this - I think it's awesome. So many times when debugging code I've attempted to write import std.stdio; in the function, then had to move it away from the code I was debugging - of course this left a stray import because I forgot about it :3

-- 
Robert
http://octarineparrot.com/

I'm having some fun with this.

import std.array;

void main()
{
    with (namespace!("std.stdio std.algorithm std.range"))
    {
        auto squares = map!("a * a")([2, 4, 6]);
        writeln(squares);
    }
}

template namespace(string x)
{
    mixin(namespaceImpl(x));
}

string namespaceImpl(string x)
{
    string result;
    auto mods = split(x);
    foreach (val; mods)
    {
        result ~= "import " ~ val ~ ";";
    }
    return result;
}

Btw, it's disappointing that I can't call split with a separator at compile-time:

enum result = split("bla, bla");  // ok
enum result = split("bla, bla", ",");  // nope

On Jun 14, 11 03:55, Andrej Mitrovic wrote:
> Btw, it's disappointing that I can't call split with a separator at
> compile-time:
>
> enum result = split("bla, bla");  // ok
> enum result = split("bla, bla", ",");  // nope

That's due to (at least) http://d.puremagic.com/issues/show_bug.cgi?id=4047.

Walter, it looks like this addition inadvertently fixes the issue of DLLs not linkable due to Phobos imports.

I've had this DLL (alongside with dllmodule.d which had initialization
calls inside DLLMain):
module EdrLib;

import std.utf;

pragma(lib, "gdi32.lib");
pragma(lib, "comdlg32.lib");
import win32.windef;
import win32.wingdi;

export extern(Windows) BOOL EdrCenterText(HDC hdc, PRECT prc, string pString)
{
     SIZE size ;
     GetTextExtentPoint32(hdc, pString.toUTF16z, pString.length, &size) ;
     return TextOut(hdc, (prc.right - prc.left - size.cx) / 2,
                         (prc.bottom - prc.top - size.cy) / 2,
pString.toUTF16z, pString.length);
}

The header file produced from this would cause any client code which imports the header to look for ModuleInitZ, which wouldn't exist in the generated import library since it's an import library and not a static library.

But, if I move the phobos import inside the EdrCenterText function:

export extern(Windows) BOOL EdrCenterText(HDC hdc, PRECT prc, string pString)
{
     import std.utf;

     SIZE size ;
     GetTextExtentPoint32(hdc, pString.toUTF16z, pString.length, &size) ;
     return TextOut(hdc, (prc.right - prc.left - size.cx) / 2,
                         (prc.bottom - prc.top - size.cy) / 2,
pString.toUTF16z, pString.length);
}

Then it works. My related bug report about this (and its complicated to read due to various misunderstanding on my part) is http://d.puremagic.com/issues/show_bug.cgi?id=6019.

But it's great that there's an actual workaround now!

On 6/13/2011 8:28 PM, Andrej Mitrovic wrote:
> Walter, it looks like this addition inadvertently fixes the issue of DLLs not linkable due to Phobos imports.
> 
> I've had this DLL (alongside with dllmodule.d which had initialization
> calls inside DLLMain):
> module EdrLib;
> 
> import std.utf;
> 
> pragma(lib, "gdi32.lib");
> pragma(lib, "comdlg32.lib");
> import win32.windef;
> import win32.wingdi;
> 
> export extern(Windows) BOOL EdrCenterText(HDC hdc, PRECT prc, string pString)
> {
>      SIZE size ;
>      GetTextExtentPoint32(hdc, pString.toUTF16z, pString.length, &size) ;
>      return TextOut(hdc, (prc.right - prc.left - size.cx) / 2,
>                          (prc.bottom - prc.top - size.cy) / 2,
> pString.toUTF16z, pString.length);
> }
> 
> The header file produced from this would cause any client code which imports the header to look for ModuleInitZ, which wouldn't exist in the generated import library since it's an import library and not a static library.
> 
> But, if I move the phobos import inside the EdrCenterText function:
> 
> export extern(Windows) BOOL EdrCenterText(HDC hdc, PRECT prc, string pString)
> {
>      import std.utf;
> 
>      SIZE size ;
>      GetTextExtentPoint32(hdc, pString.toUTF16z, pString.length, &size) ;
>      return TextOut(hdc, (prc.right - prc.left - size.cx) / 2,
>                          (prc.bottom - prc.top - size.cy) / 2,
> pString.toUTF16z, pString.length);
> }
> 
> Then it works. My related bug report about this (and its complicated to read due to various misunderstanding on my part) is http://d.puremagic.com/issues/show_bug.cgi?id=6019.
> 
> But it's great that there's an actual workaround now!

This makes me think that there's actually a bug in the function-local imports.  I'm guessing they don't run module-level ctors and dtors for the imported modules.  Would you mind putting together a test case to check?

Thanks,
Brad

When I add module ctors/dtors, I get the ModuleInfoZ shenanigans again.

And they do run, I've tested it in a non-DLL example.

I'm guessing this is what you're after:

http://codepad.org/TCtG68Fw
http://codepad.org/65GBDjPS

rdmd main.d
shared ctor!
ctor!
foo.test
dtor!
shared dtor!

Should DLLs even have module ctors/dtors?

I think this is what DLLMain's DLL_PROCESS_ATTACH, DLL_THREAD_ATTACH and their detach counterparts are for.