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