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