Thread overview
What std functions are CTFE?
Aug 19, 2013
Borislav Kosharov
Aug 19, 2013
bearophile
Aug 19, 2013
monarch_dodra
Aug 19, 2013
bearophile
Aug 19, 2013
monarch_dodra
August 19, 2013
How do I know which functions are CTFE? I mean from the ones in std. I think there should be some icon or marker in the docs that indicates which function can be called during compilation.

I remember that there was a compile time bool that checks if the current function is called during compilation(__ctfe I think). But that is used only in the implementation of the function. Is there some kind of attribute(@ctfe for ex) that forces the compiler to check if the function is @ctfe without using it anywhere.

I would really like to see the std documented in a more pleasant visual way. By using icons that replace the long declarations of the functions(something like MSDN maybe).

If such documenting tool exists please tell. I know for DDoc, bootDoc and others, but none of them(not sure) can replace attributes like @property, pure, static and others with icons.
August 19, 2013
Borislav Kosharov:

> How do I know which functions are CTFE?

While Don improve CTFE, the number of CTFE-able functions increases.


> I know for DDoc, bootDoc and others, but none of them(not sure) can replace attributes like @property, pure, static and others with icons.

Perhaps with ddoc you can introduce simple macros that replace attributes with Unicode symbols or HTML links to icons.

Bye,
bearophile
August 19, 2013
On Monday, 19 August 2013 at 11:34:48 UTC, bearophile wrote:
> Borislav Kosharov:
>
>> How do I know which functions are CTFE?
>
> While Don improve CTFE, the number of CTFE-able functions increases.

What bearophile said. The amount of functions that can be CTFE'd is increasing everyday.

It *would* though be nice to document it as such (eg $(CTFEable) ).

That said, it is also kind of like @safe and nothrow: For templates, it'll really depend on the arguments: For example, Appender!(char*) can be CTFE'd, but chances are it won't work for a struct with postblit.

But yes, I think we need to document better.
August 19, 2013
monarch_dodra:

> But yes, I think we need to document better.

Eventually it will be a good idea to add tests inside the Phobos unittests to make sure functions keep being CTFE-able. I have seen many regressions on this along the time.

Bye,
bearophile
August 19, 2013
On Monday, 19 August 2013 at 12:38:42 UTC, bearophile wrote:
> monarch_dodra:
>
>> But yes, I think we need to document better.
>
> Eventually it will be a good idea to add tests inside the Phobos unittests to make sure functions keep being CTFE-able. I have seen many regressions on this along the time.
>
> Bye,
> bearophile

As we are seeing that functions are CTFE-able, we are addnig more and more CTFE tests (as well as @safe/pure).

The "problem" is that we started with simple implementations. These were a bit slower, but easilly safe/pure/ctfe. Then, we decided to "upgrade" these, doing more "under the hood" for speed. This usually broke all the above. We are now slowly repairing these.