Stefan Koch: New CTFE fix

Moritz Maxeiner via Digitalmars-d digitalmars-d at puremagic.com
Mon Aug 14 21:31:43 PDT 2017


On Tuesday, 15 August 2017 at 01:41:58 UTC, Johnson wrote:
> On Tuesday, 15 August 2017 at 01:31:13 UTC, Moritz Maxeiner 
> wrote:
>> On Monday, 14 August 2017 at 22:51:04 UTC, Johnson Jones wrote:
>>>
>>> string do()
>>> {
>>>    string x;
>>>    x = "adsf";
>>>    pragma(msg, x);
>>>    return x;
>>> }
>>
>> "do" is a keyword in D, you can't use it as an identifier.
>>
>
> wow, way to fail to realize generalities.

The failure lies on your side in not providing syntactically 
valid code in a discussion that's about semantics.

>
>>>
>>> fails because the compiler believes that x is not known at 
>>> compile time.
>>
>> There are multiple phases making up D's compile time, the wiki 
>> has an excellent page by H. S. Teoh on the subject [1]. 
>> Applied to your example: The pragma in the function body is 
>> handled before the function body is interpreted, so the 
>> compiler error is correct; whether or not the error message 
>> should be more explicit is another matter.
>
> So, that is a generic answer for a generic post. It says 
> nothing about what can be done, but what only can't be done.

Then I have to assume you haven't read the page I linked to, 
since it describes the different compile time mechanics and how 
they interact with each other (i.e. what you can do with them).

> There is nothing stopping one's ability to output compile time 
> information at compile time from compile time functions. Again, 
> way to fail to realize generalities.

The failure lies with you being unwilling to acknownledge the 
different phases of compile time; specifically, that pragmas 
cannot access variables initialized in CTFE (__ctfeWrite can, 
however).

> Just because something [rant]

You are entitled to your opinion, but it's not relevant in this 
(technical) discussion.

>
>
>
>>> It obviously is when do is ran as a ctfe. This makes some 
>>> types of programming difficult to debug because we have to 
>>> duplicate any instance of "do" and cannot output intermediate 
>>> values.
>>>
>>> But, how can we make this actually work?
>>>
>>> [...]
>>
>> I recommend reading up on the history of CTFE output in 
>> D[2][3][4][5][6].
>> If you want to see CTFE output in D, you could pick up where 
>> Stefan left off in the latest attempt[6].
>>
>> [1] 
>> https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time
>> [2] 
>> http://www.digitalmars.com/d/archives/digitalmars/D/CTFE_writeln_140241.html
>> [3] http://forum.dlang.org/thread/j1n0l7$235r$1@digitalmars.com
>> [4] https://github.com/dlang/dmd/pull/296
>> [5] https://github.com/dlang/dmd/pull/692
>> [6] https://github.com/dlang/dmd/pull/6101
>
> It seems like he's already done all the heavy lifting and who 
> knows best rather than him to implement it in his own redesign 
> of ctfe(to fix the mess that it was in precisely for the 
> reasons I stated above)?

newCTFE is not a redesign of the compile time architecture, it is 
more performant CTFE engine (Period). That being said, anyone who 
wants to tackle a small issue to contribute to D could've 
implemented __ctfeWrite. My own ~30 minute attempt (of which 25+ 
minutes were spent reading dmd source) is open [1].

[1] https://github.com/dlang/dmd/pull/7082


More information about the Digitalmars-d mailing list