Re: BetterC and CTFE mismatch
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.
Re: BetterC and CTFE mismatch
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.
Re: BetterC and CTFE mismatch
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
Re: BetterC and CTFE mismatch
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).
Re: BetterC and CTFE mismatch
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?
Re: BetterC and CTFE mismatch
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
