A Perspective on D from game industry

[H. S. Teoh via Digitalmars-d]

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!