http://d.puremagic.com/issues/show_bug.cgi?id=11172

           Summary: Allow scoped assignment of version and debug
                    statements
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: andrej.mitrovich@gmail.com


--- Comment #0 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-10-04 07:36:56 PDT ---
-----
void foo() { }

void main()
{
    version = CALL_FOO;
    version (CALL_FOO)
    {
        foo();
    }

    debug = DEBUG_FOO;
    debug (DEBUG_FOO)
    {
        foo();
    }
}
-----

$ dmd test.d
test.d(5): Error: (condition) expected following version
test.d(5): Error: found '=' instead of statement
test.d(11): Error: found '=' instead of statement

Allowing this would mean the version/debug identifiers were valid inside the
scope of the assignment. Outside of main() a version(CALL_FOO) body would not
be entered.

The workaround is use to use enums and static if:

-----
void foo() { }

void main()
{
    enum CALL_FOO = 1;
    static if (CALL_FOO)
    {
        foo();
    }

    enum DEBUG_FOO = 1;
    static if (DEBUG_FOO)
    {
        foo();
    }
}
-----

But it would be more convenient to allow the former version/debug syntax, especially if we want to re-use existing version/debug identifiers.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11172


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com


--- Comment #1 from Walter Bright <bugzilla@digitalmars.com> 2013-10-04 12:01:45 PDT ---
I'm pretty strongly opposed to this. These should have module scope, and no other scope. Version and debug identifiers are special and live outside the normal symbol table, and this is on purpose. They cannot be imported from other modules, and do not affect imported modules.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11172



--- Comment #2 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-10-04 12:15:03 PDT ---
(In reply to comment #1)
> They cannot be imported from other
> modules, and do not affect imported modules.

Right, but they can be set in the module itself:

-----
version = CALL_FOO;  // active in this module only
void foo() { }

void main()
{
    version (CALL_FOO)
    {
        foo();
    }
}
-----

I was looking for a more fine-grained version of this. The reason why is that two code fragments which are related to each other should also be closer to each other (in this case CALL_FOO is only used inside a single function). In a large module I could easily miss that a version switch was set.

Personally I dislike that version/debug statements are global to begin with. It's only a matter of time before two libraries end up having two conflicting notions of the same version/debug symbol.

For example if libFoo has a version(SharedLib) block, but libBar also uses this same version block but for a completely different purpose you will end up enabling the block for both libraries even if you only wanted to do it for a single library.

It very much reminds me of a C macro. I guess you can close this, I can use 'static if' instead.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11172


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> 2013-10-04 12:27:54 PDT ---
(In reply to comment #2)
> For example if libFoo has a version(SharedLib) block, but libBar also uses this same version block but for a completely different purpose you will end up enabling the block for both libraries even if you only wanted to do it for a single library.

This is exactly why version identifiers are not imported and are not affected by who imports them. They can only be set via the command line or in the module itself.

> It very much reminds me of a C macro.

In some ways, but C macros are extremely unhygienic. They invade the imports and are imported from imports in a most unpleasant fashion.

> I guess you can close this, I can use
> 'static if' instead.

Thank you.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11172



--- Comment #4 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-10-04 12:32:43 PDT ---
(In reply to comment #3)
> This is exactly why version identifiers are not imported and are not affected by who imports them. They can only be set via the command line or in the module itself.

Once you set them at the command line they affect *every* library that you import, that's still an issue.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11172



--- Comment #5 from Walter Bright <bugzilla@digitalmars.com> 2013-10-04 12:52:06 PDT ---
(In reply to comment #4)
> Once you set them at the command line they affect *every* library that you import, that's still an issue.

I agree, and library developers should be aware of this and account for it. My recommendation is that library developers need to eschew using generic version identifiers, and instead use a prefix consisting of the library name.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11172



--- Comment #6 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-10-04 13:02:45 PDT ---
(In reply to comment #5)
> My recommendation is that library developers need to eschew using generic version identifiers, and instead use a prefix consisting of the library name.

Yeah. I'm doing this in my own libraries too.

But since each library practically owns the toplevel package name (each library name is unique, after all), we could avoid depending on naming conventions and instead allow using the package or module name before an identifier:

version (foolib.SharedLib) { }

Then from the command line you would call:

$ dmd -lib -version=foolib.SharedLib foolib.d

Is it overkill? The alternative is to manually encode the name and use `version=foolib_SharedLib`, but it's a bit ugly.

I could see some use-cases:

version=std.perf_tests => enable performance test suite in all of phobos version=std.datetime.perf_tests => enable the same just for datetime

Of course these would still be visible globally, but there's no need for name encoding conventions if this is allowed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11172



--- Comment #7 from Walter Bright <bugzilla@digitalmars.com> 2013-10-05 01:10:08 PDT ---
Yes, I think it is overkill.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------