www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - BetterC and CTFE mismatch

reply Sebastiaan Koppe <mail skoppe.eu> writes:
Right now I am building a betterC application and I would have 
expected to be able to use the D standard library in CTFE.

It seems this is not the case. Can anyone explain why? It seems 
to be an arbitrary limitation.

example: 
https://run.dlang.io/gist/8ee9456bfae061eba81c931999183e49?args=-betterC
Sep 26 2018
parent reply Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Wednesday, 26 September 2018 at 08:06:27 UTC, Sebastiaan Koppe 
wrote:

 Right now I am building a betterC application and I would have 
 expected to be able to use the D standard library in CTFE.

 It seems this is not the case. Can anyone explain why? It seems 
 to be an arbitrary limitation.

 example: 
 https://run.dlang.io/gist/8ee9456bfae061eba81c931999183e49?args=-betterC


This is essentially an arbitrary restriction. The basic reason is 
if a function is compiled (even just for CTFE), it ends up in the 
object files, and you've asked for only betterC functions to end 
up in the object files.

--
   Simen
Sep 26 2018
parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Wednesday, 26 September 2018 at 08:22:26 UTC, Simen Kjærås 
wrote:

 This is essentially an arbitrary restriction. The basic reason 
 is if a function is compiled (even just for CTFE), it ends up 
 in the object files, and you've asked for only betterC 
 functions to end up in the object files.

 --
   Simen


So anything I do at CTFE has to be betterC as well? That is a 
bummer.

I'll try to workaround this, but I would like to see this fixed. 
Is there anything I can do to move this forward?
Sep 26 2018
next sibling parent learnfirst1 <learnfirst1 gmail.com> writes:
On Wednesday, 26 September 2018 at 09:08:06 UTC, Sebastiaan Koppe 
wrote:

 On Wednesday, 26 September 2018 at 08:22:26 UTC, Simen Kjærås 
 wrote:

 This is essentially an arbitrary restriction. The basic reason 
 is if a function is compiled (even just for CTFE), it ends up 
 in the object files, and you've asked for only betterC 
 functions to end up in the object files.

 --
   Simen


 So anything I do at CTFE has to be betterC as well? That is a 
 bummer.

 I'll try to workaround this, but I would like to see this 
 fixed. Is there anything I can do to move this forward?


You can call Non-BetterC function from import path. (not from the 
source code, but in the import path).
Sep 26 2018
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/26/18 5:08 AM, Sebastiaan Koppe wrote:

 On Wednesday, 26 September 2018 at 08:22:26 UTC, Simen Kjærås wrote:

 This is essentially an arbitrary restriction. The basic reason is if a 
 function is compiled (even just for CTFE), it ends up in the object 
 files, and you've asked for only betterC functions to end up in the 
 object files.

 -- 
   Simen


 
 So anything I do at CTFE has to be betterC as well? That is a bummer.


This is an artificial, and not really intended, limitation. Essentially, 
CTFE has to be a real function. If it's defined, it's expected to be 
callable from runtime as well as CTFE.

But I can't see why, if you don't call from runtime, it should matter. I 
think this has to do with the places betterC is enforced in the compiler.


 
 I'll try to workaround this, but I would like to see this fixed. Is 
 there anything I can do to move this forward?


I'd suggest a bug report if one hasn't been made.

-Steve
Sep 26 2018
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 26 September 2018 at 12:51:57 UTC, Steven 
Schveighoffer wrote:

 So anything I do at CTFE has to be betterC as well? That is a 
 bummer.


 This is an artificial, and not really intended, limitation. 
 Essentially, CTFE has to be a real function. If it's defined, 
 it's expected to be callable from runtime as well as CTFE.

 But I can't see why, if you don't call from runtime, it should 
 matter. I think this has to do with the places betterC is 
 enforced in the compiler.


 
 I'll try to workaround this, but I would like to see this 
 fixed. Is there anything I can do to move this forward?


 I'd suggest a bug report if one hasn't been made.

 -Steve


https://issues.dlang.org/show_bug.cgi?id=18472 is an open 
regression on 2.078. Doesn't cover all use cases of what 
Sebastiaan might want though.
Sep 26 2018
prev sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Wednesday, 26 September 2018 at 12:51:57 UTC, Steven 
Schveighoffer wrote:

 I'd suggest a bug report if one hasn't been made.

 -Steve


I found https://issues.dlang.org/show_bug.cgi?id=19268 and I have 
appended my case there.
Sep 26 2018