On Tue, Jun 17, 2014 at 06:58:27PM +0000, via Digitalmars-d wrote: > On Tuesday, 17 June 2014 at 18:24:22 UTC, H. S. Teoh via Digitalmars-d > wrote: > >How would the compiler (or any tool!) detect the use (or non-use) of > >deprecated features here? > > You compile it or detect AST-node presence.
You can also compile a string mixin to detect if it uses deprecated features, no? But that's missing my point. My point was that CTFE makes automated detection of deprecated features (or any property of a particular piece of code, really) a rather tricky proposition. For example: static if (longComplicatedComputation()) badFeature(); else goodFeature(); What if badFeature() is never compiled because longComplicatedComputation() always returns 0? But the compiler may not be able to statically prove that this is always the case -- in the worst case, it's tantamount to solving the halting problem. Plus, attempting CTFE in real-time inside an IDE may not be a good idea -- a longish compile-time computation (say 10 seconds long) may be OK for batch compilation, but it's not acceptable for an IDE to pause 10 seconds every time you browse that piece of code just because the IDE needs to compute whether or not it should highlight badFeature() as a deprecated feature. Also, detecting AST node presence is unreliable. What if it's needed for compatibility with older compilers? static if (__VERSION__ < 2064L) useDeprecatedFeature(); else useNewFeatureNotIn2064(); This piece of code may be absolutely fine because both older and newer compilers will accept it. But AST node presence would flag the code as problematic because of useDeprecatedFeature. And if you ignore that branch by assuming __VERSION__ == the latest compiler version, then you are no longer validating *all* branches of the code, which you stated in your previous post was an important goal. Basically, metaprogramming does come with a price -- some things may become difficult/impractical to automate. But it also enables use cases for which a language without any metaprogramming features would be unable to handle (or would require much uglier ways to implement). > >If you want it to run in a browser, and the browser doesn't support > >certain language features, then you'll just have to restrict your code > >to the subset of the language that's implementable in a browser, no? > > And avoid standard libraries? AFAIK, Phobos doesn't heavily use string mixins, does it? > Javascript supports eval() so it can support string mixins in theory, > even at runtime, but if you cannot easily translate the mixin content > then you have a challenge. > > Not that D is meant for web browsers, but my point is more that > macro-like features has consequences that go beyond the compiler > internals. I'm certainly not saying that string mixins don't have consequences beyond compiler internals. In fact, I don't particularly like them myself, but they do fill a gap that would otherwise be in the language for certain cases of metaprogramming. The original intention, AFAICT, was to replace string mixins with AST macros, but since the latter never materialized, string mixins is what we're left with. In any case, they're relatively rarely used, so I don't see them as the big problem that you seem to consider them to be. T -- Ignorance is bliss... until you suffer the consequences!