digitalmars.D.bugs - [Issue 11172] New: Allow scoped assignment of version and debug statements
- d-bugmail puremagic.com (59/59) Oct 04 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11172
- d-bugmail puremagic.com (13/13) Oct 04 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11172
- d-bugmail puremagic.com (31/33) Oct 04 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11172
- d-bugmail puremagic.com (17/24) Oct 04 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11172
- d-bugmail puremagic.com (8/11) Oct 04 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11172
- d-bugmail puremagic.com (9/11) Oct 04 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11172
- d-bugmail puremagic.com (20/22) Oct 04 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11172
- d-bugmail puremagic.com (6/6) Oct 05 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11172
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
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
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
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
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
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
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
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