http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #5 from Chad Joan <[email protected]> 2009-07-30 01:50:28 PDT --- (In reply to comment #4) > > I think you are right that it can be determined in simple cases, but for sure > there will be cases that the compiler cannot diagnose, such as: > > int _global; > > struct S > { > int _x; > version(noop) > void x(int n) { _x = n;} > else > void x(int n) { _global = n;} > } > > struct S2 > { > S foo() { return S(5);} > } > > void main() > { > S2 s2; > s2.foo.x = 5; > } > > How does the compiler know when compiling with noop that the s2.foo.x = 5 > doesn't do anything? Especially if the module containing main is using a di > file to define S and S2. > > The result is, I don't think the compiler can diganose the complex cases, and > most of the time, the cases are complex. It's easy for the compiler to know that "s2.foo.x = 5" does nothing. When compiling with noop, the "void x(int n) { _global = n;}" version just does not get compiled. Period. When "s2.foo.x = 5;" is being analysed, the compiler will walk the syntax tree for "void x(int n) { _x = n;}" and discover that s2.foo is an rvalue. This is what it already does, minus the "discover that s2.foo is an rvalue" part. Of course, s2.foo().x(5) violates the principle at play here. At this point, the whole "version(noop)" thing is just fluff, and here is the meat of the matter. In this example, "s2.foo.x = 5;" does actually do something and is reasonable code. However, naively forbidding an rvalue on the lhs of an assign expression will make that code fail to compile. I don't feel that code like this is terribly common or that much better than the alternatives, so it is probably worth losing some corner cases like these for the sake of preventing nasty bugs. .di files change absolutely nothing. They are .d files that just happen to be mostly definitions because dmd generated that way. There is nothing in the spec saying that they even need to exist. More importantly, Walter was intentional about omitting them from the spec. "D interface files bear some analogous similarities to C++ header files. But they are not required in the way that C++ header files are, and they are not part of the D language. They are a feature of the compiler, and serve only as an optimization of the build process." http://www.digitalmars.com/d/2.0/dmd-linux.html#interface_files -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
