www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11172] New: Allow scoped assignment of version and debug statements

reply d-bugmail puremagic.com writes:
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



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: -------
Oct 04 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11172


Walter Bright <bugzilla digitalmars.com> changed:

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



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: -------
Oct 04 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11172




12:15:03 PDT ---


 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: -------
Oct 04 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11172


Walter Bright <bugzilla digitalmars.com> changed:

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



12:27:54 PDT ---


 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: -------
Oct 04 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11172




12:32:43 PDT ---


 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: -------
Oct 04 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11172




12:52:06 PDT ---


 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: -------
Oct 04 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11172




13:02:45 PDT ---


 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: -------
Oct 04 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11172




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: -------
Oct 05 2013