Getting the error from __traits(compiles, ...)

[Bill Baxter]

On Fri, Nov 13, 2009 at 9:38 AM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> Bill Baxter wrote:
>>
>> On Fri, Nov 13, 2009 at 8:40 AM, bearophile <bearophileHUGS at lycos.com>
>> wrote:
>>>
>>> Bill Baxter:
>>>>
>>>> 2) how to get and report errors related to failure to compile some
>>>> code. (this one I hadn't thought of back then)
>>>
>>> I'd like a "static foreach" too. Eventually most statements will have a
>>> static version. At that point people will start seeing this little
>>> duplication in the language and someone may invent a way to throw away all
>>> the static versions and allow normal D code to be used at compile time,
>>> maybe with a 2-stage compilation or something.
>>
>> A static switch would be nice too.   static if (is(type == xxx)) {}
>> else static if (is(type==yyy)) {} else static if ... gets kinda
>> tedious.
>>
>>
>> The kind of unification you're talking about is one thing I like about
>> Nemerle's 2-phase macros-as-plugins.  The code you execute at compile
>> time is written in exactly the same language as what you execute at
>> runtime.  And no CTFE engine is required to make it work.  Only one
>> new construct required, the macro facility itself.
>>
>> But I don't think that leads to elimination static if, etc.  It just
>> means that such things become implementable as macros, rather than
>> language constructs.
>>
>> On the other hand, having macros doesn't mean that you don't want
>> constant folding.  And if you can fold the constant 2+3, why not the
>> constant add(2,3)?  So desire to fold as many constants as possible
>> naturally leads to a desire to do CTFE and be able to execute your
>> entire language at compile time.
>>
>> And once you're there -- yeh, I guess you're right.   Ultimately it's
>> not really necessary to specify static if vs regular if.   It's yet
>> another extension of constant folding -- if the condition is a compile
>> time constant, then it can act as a static if.   Same goes for loops.
>> But like regular loop unrolling optimizations, the compiler should
>> decide if it's prudent to unroll that 10,000 static foreach loop or
>> not.
>>
>> So in short.  I think you're right.  "static if"  should go away.  But
>> "2-stage" compilation isn't really necessary, just more extensions to
>> the constant folding engine.  (Or perhaps you could say constant
>> folding is already a separate stage of a 2-stage process)
>
>
> "static if" is different from "if" in the way it handles scopes.

Good point.  It's not really an essential distinction, though.  If the
language had no-scope blocks in addition to scope blocks then you
could have no-scope dynamic if() also.

I've always found it unpleasing anyway that one word (somewhat
separated from the {}) changes whether {} creates a scope or not.

> Also, the
> former is a declaration, the latter is a statement.

That mostly just means you can use "static if" at the top level, right?
If the language eliminated "static if" then clearly all if's at the
top level would be required to have static conditions and use no-scope
blocks.

But ok.  These things probably make it too big a change for D to swallow.

--bb