CTFE Ability

[jaypha]

Hi

I am using D-yaml in some of my projects, and would like to be able to use it in a compile time executed function. I was wondering if you would be willing to consider making D-Yaml CTFE friendly.

Thanks for your time.

[kiith-sa]

This is a good idea, though likely to require quite a bit of work. I might get to it eventually but not in near future (pull requests welcome) - I'll keep this open.

[Herringway]

Biggest blockers to this appear to be std.regex and a few of the data structures (Queue, Array, etc?) used throughout D-YAML.

[tom-tan]

Biggest blockers to this appear to be std.regex and a few of the data structures (Queue, Array, etc?) used throughout D-YAML.

Now one blocker due to std.regex is solved by #266 and the rest of main blockers are the use of the data structures in D-YAML such as dyaml.queue.Queue.

Currently,

• dyaml.queue.Queue stores the stock variable for a free-list of Node, and
• each Node is allocated by using std.experimental.allocator.mallocator
  • use of mallocator is a reason why D-YAML cannot be CTFEable

However, I doubt both are needed to prevent too much reallocation. Is it enough to use a free-list of GC-allocated Node objects?

[Herringway]

the std.regex blocker has only been partially solved. matching still doesn't work at compile time.

[tom-tan]

Thank you for your information!

I missed the other places that are blocked by std.regex because I checked CTFEability only with the following code.

unittest
{
    import dyaml.loader;
    enum str = q"EOS
Hello World : [Hello, World]
Answer: 42
EOS";
    enum root = Loader.fromString(str).load();
}

It shows the following error message.

$ dub test
...
source/dyaml/queue.d(61,22): Error: static variable instance cannot be read at compile time
...

So currently I search for the possibility to get rid of Mallocator.instance for the next step.

[Herringway]

yeah, it doesn't get far enough to trigger the regex errors. you could work around the other issues by just adding special cases for CTFE, since GC/not-GC doesn't really matter much there. there's just little point in actually doing so as long as the regex issue exists

[tom-tan]

FYI:

I dived into std.regex a little. I found that most of the blockers to make std.regex CTFEable can be solved by using __ctfe but unsafe casts and impure functions are the biggest blocker to make it CTFEable.

Fixing them seems to be a difficult task because we cannot ignore @safe and pure using @trusted or attribute modifications during CTFE unlike runtime.

There is a workaround to fix CTFEability of D-YAML. Currently constructor.d in D-YAML is the only place that cannot be CTFEable due tostd.regex.

If we can get rid of the use of std.regex from constructor.d, I guess D-YAML can become CTFEable. Howover, it is not so easy task and also the resulted code may become trickier than the current code.

[Herringway]

removing regex support is out of the question, since it's part of the spec (and will be more important later with schemas). I do have other ideas on how to approach this, though. I'm planning to remove types from Node and placing construction on top of that, which would make it optional. then that can be transformed into full schema support, which we'll see when YAML 1.2 is implemented. the failsafe schema in particular would require no regexes and should be usable in CTFE. Unfortunately, this isn't a small task. There are a lot of corner cases to hammer out still...