http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #8 from BCS <shro8...@vandals.uidaho.edu> 2009-07-30 09:23:10 PDT --- (In reply to comment #5) > > 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. This assumes that the body of x is available for analysis and is simple enough to be analysed. The first will not be true of any C function, any function that calls a C function (etc.), any closed source lib or any function that calls into a closed source lib (etc.). The second will not be true in general because it can devolve into the halting problem. To keep things consistent, the rules used have to be defined in the spec, practicely ruling out powerful heuristics and computation logic systems, and have to act the same regardless of accessability to source, strongly ruling out anything that uses inter-procedural analysis (Walter has several times stated that semantic rules that require analysis of non local code are not going to happen). > .di files change absolutely nothing. Technically, yes. .di files don't actually /add/ any problems here because the problems at issue can be caused by a .d file as well. > 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. Any implementation that doesn't give the same functionality as .di files (no-source symbol decelerations) effectively eliminates the ability to have closed source D libraries. Therefor, the feature causing problems effectively is part of the spec. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------