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

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

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?

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).

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

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.

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.