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

[Don]

Yigal Chripun wrote:
> On 13/11/2009 22:05, Bill Baxter wrote:
>> On Fri, Nov 13, 2009 at 11:50 AM, Yigal Chripun<yigal100 at gmail.com>  
>> wrote:
>>>
>>> I don't follow your logic regarding CTFE.
>>>
>>> with 2 phase macros a-la nemerle:
>>>
>>> macro foo() {
>>>   int res = 2 + 3;
>>>   return res;
>>> }
>>>
>>> macro bar() {
>>>   return q{2 + 3};
>>> }
>>>
>>> foo's addition is done at compile time so the constant folding was
>>> implemented in the macro body
>>>
>>> bar return the AST for the expression "2 + 3". Compiler optimizations 
>>> like
>>> constant folding will apply just as if you wrote that expression 
>>> yourself
>>> instead of generating it by calling a macro.
>>
>> Right, which is why I'm saying you still want constant folding/CTFE
>> even if you have a macro system.  But then if you're going to have
>> CTFE sitting around anyway, you might as well use it to implement
>> macros instead of going to this funky two-phase thing.   That was one
>> point I was making, though not so clearly.
>>
>>> static if is not supposed to be implemented with macros, rather the
>>> equivalent of a static if would be using a regular if *inside* the 
>>> body of
>>> the macro.
>>
>> But that's how you would implement a static if with macros, no?
>> (pardon the incorrect nemerle syntax)
>>
>> macro static_if(bool cond, a, b) {
>>          if (cond) {
>>             <|  a  |>
>>          } else {
>>             <|  b  |>
>>          }
>> }
>>
>> --bb
> 
> let's start from the end,
> yes, you can implement static if that way but I don't see why would you 
> want to do that.
> 
> regarding constant folding and 2 phase compilation:
> from what I know, DMD currently contains inside two backends, the 
> regular one generates the executable *and* an interpreter which does 
> CTFE

> Constant folding is an optimization used by both.
> 
> basically we already have two phases of compilation but they are done 
> internally by DMD. This means that DMD has two separate backends instead 
> of just one and that you need separate syntax to target the different 
> phases.
> 
> The major problems I see with the current system:
> - unnecessary duplication of syntax
> - two backends instead of just one which complicates the compiler 
> implementation

There's only one backend. The interpreter is basically just constant 
folding, with a small amount of interpreting of statements. 90% of the 
CTFE complexity is in the constant folding. The interpreter itself is 
only about 200 lines of code. But the real backend is huge.

> - unclear separation of phase in code:
>   auto arr = [1.0, 2.0, bar(5.0)]; // when is bar executed?
> also, how can I control when it's executed? This is needlessly confusing 
> and doesn't provide enough control to the programmer.

That particular example is caused by array literals not being immutable, 
which I am certain is a mistake.

> it's analogous to structs vs. classes. I'm sure everyone in the D 
> community agree that this separation of concerns is much better than the 
> bug-prone c++ way.