On Monday, 25 June 2018 at 07:02:24 UTC, Jonathan M Davis wrote:
On Monday, June 25, 2018 05:47:30 Mr.Bingo via
Digitalmars-d-learn wrote:
The problem then, if D can't arbitrarily use ctfe, means that
there should be a way to force ctfe optionally!
If you want to use CTFE, then give an enum the value of the
expression you want calculated. If you want to do it in place,
then use a template such as
template ctfe(alias exp)
{
enum ctfe = exp;
}
so that you get stuff like func(ctfe!(foo(42))). I would be
extremely surprised if the compiler is ever changed to just try
CTFE just in case it will work as an optimization. That would
make it harder for the programmer to understand what's going
on, and it would balloon compilation times. If you want to
write up a DIP on the topic and argue for rules on how CTFE
could and should function with the compiler deciding to try
CTFE on some basis rather than it only being done when it must
be done, then you're free to do so.
https://github.com/dlang/DIPs
But I expect that you will be sorely disappointed if you ever
expect the compiler to start doing CTFE as an optimization.
It's trivial to trigger it explicitly on your own, and
compilation time is valued far too much to waste it on
attempting CTFE when in the vast majority of cases, it's going
to fail. And it's worked quite well thus far to have it work
only cases when it's actually needed - especially with how easy
it is to make arbitrary code run during CTFE simply by doing
something like using an enum.
- Jonathan M Davis
You still don't get it!
It is not trivial! It is impossible to trigger it! You are
focused far too much on the optimization side when it is only an
application that takes advantage of the ability for rtfe to
become ctfe when told, if it is possible.
I don't know how to make this any simpler, sorry... I guess we'll
end it here.
