Is betterC affect to compile time?

[Jonathan M Davis]

On Thursday, July 25, 2019 6:13:38 PM MDT Mike Franklin via Digitalmars-d-
learn wrote:
> On Thursday, 25 July 2019 at 18:37:49 UTC, Jonathan M Davis wrote:
> > There's probably at least one bug report on it, but as I
> > understand it, it's not a bug in the sense that the
> > implementation is currently expected to handle such a case.
> > It's an area where betterC should be improved upon, but it
> > would be an enhancement, not a bug fix.
>
> Yes.  The point is that libraries have to be written with betterC
> and compile-time evaluation in mind.  If they aren't the code is
> likely not going to work in those use cases.  Much of the code in
> Phobos was written long before betterC was introduced.
>
> There are probably changes that could be made to Phobos so the OP
> could get a build, but that requires someone with enough interest
> in the issue to volunteer their time and talent to improve the
> implementation for betterC and compile-time use cases.
>
> We have a GSoC student making changes the druntime to help with
> this matter and I have been picking away at it too.  It will take
> time and could use more contributors.

I honestly don't see why how the library works should matter for CTFE so
long as it's CTFE-able. format creates a string, and mixin then mixes in
that string as code. None of that should have any effect on the generated
code or what happens at runtime beyond the code that's mixed in. Sure,
whether a library can be used with betterC at runtime depends on how the
library was implemented, but runtime is a completely different beast from
compile time. IMHO, the fact that you can't use format to create a
compile-time construct with betterC is purely a problem with dmd's current
implementation.

- Jonathan M Davis