Request for Comment assert(__ctfe)

Stefan Koch uplink.coder at googlemail.com
Wed Apr 8 08:42:52 UTC 2020


On Wednesday, 8 April 2020 at 07:09:11 UTC, Johannes Pfau wrote:
> Am Tue, 07 Apr 2020 17:13:54 -0400 schrieb Steven Schveighoffer:
>
>> On 4/7/20 12:53 PM, Johannes Pfau wrote:
>>> [...]
>> 
>> Ironically, ctfe can't deal with TypeInfo today.
>> 
>> In the past, the issue was for functions that use TypeInfo is 
>> that the non-CTFE branch uses TypeInfo, and that can't be used 
>> in betterC, but the CTFE branch doesn't use TypeInfo, but the 
>> compiler wants to build the whole function.
>> 
>> So while this is still a problem, I don't think this fix will 
>> change that.
>> 
>> -Steve
>
> I'm not sure what exactly you're referring to, but this code 
> compiles perfactly fine:
> --------------------------
>  string generateMixin(T)(string b)
>  {
>       assert(__ctfe);
>       return "auto a = " ~typeid(T).stringof ~ ";";
>  }
>
>  void main() @nogc
>  {
>       mixin(generateMixin!string("b"));
>       pragma(msg, generateMixin!string("b"));
>  }
> --------------------------
>
>
> But it does not copile with -betterC. The point here is that 
> the "Error: TypeInfo cannot be used with -betterC" message does 
> not apply to CTFE- only functions, so this PR should be able to 
> disable the check.
>
> My primary fear here is that the current implementation checks 
> the function too late in semantic and therefore such checks (or 
> the "ensure no non-ctfe function calls ctfe-only functions" 
> check are much more difficult to implement than they should be. 
> Using a pragma or attribute would easily solve this.
>
> Maybe you'd have to introduce something analog to 
> "safetyInProgress" which is "ctfeOnlyInProgress" to make this 
> assert(__ctfe) detection fully usable? But I think this adds 
> way to much complexity. Even right now, the code of the PR 
> could probably be reduced by 1/2 when just using a pragma.

The detection of assert __ctfe in the function body _can_ be done 
very early in the process
I do not want to introduce a pragma or magic annotatation.
When existing the language is perfectly able to express (only 
runs at ctfe).

Also the PR I have open is _only_ for that.
I or someone else, might write code which does the detection 
earlier and then disables betterC checks, but this is only about 
turning off codegen.



More information about the Digitalmars-d mailing list