Thread overview | |||||||||
---|---|---|---|---|---|---|---|---|---|
|
September 26, 2018 BetterC and CTFE mismatch | ||||
---|---|---|---|---|
| ||||
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 |
September 26, 2018 Re: BetterC and CTFE mismatch | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sebastiaan Koppe | 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
|
September 26, 2018 Re: BetterC and CTFE mismatch | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen Kjærås | 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?
|
September 26, 2018 Re: BetterC and CTFE mismatch | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sebastiaan Koppe | 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).
|
September 26, 2018 Re: BetterC and CTFE mismatch | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sebastiaan Koppe | 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 |
September 26, 2018 Re: BetterC and CTFE mismatch | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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. |
September 26, 2018 Re: BetterC and CTFE mismatch | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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. |
Copyright © 1999-2021 by the D Language Foundation