Request for Comment assert(__ctfe)
Petar
Petar
Sun Apr 5 18:25:10 UTC 2020
On Sunday, 5 April 2020 at 12:11:23 UTC, Stefan Koch wrote:
> Hi Guys,
> ...
> What do you guys think?
Another, more radical and interesting option is to not perform
codegen unless it's actually necessary. Instead of blacklisting
`@ctfe` or `assert(__ctfe)` functions, have a whitelist of what
functions are allowed to codegen-ed.
Specifically, do not perform codegen for any function unless that
function:
A) is marked, or inferred as `export` or called from such
function (transitively)
B) is part of an aggregate (module, union, class, struct,
interface, template) marked as `export`, or called from a
function part of such
(By module marked as `export` I mean `export module foo;`, as
opposed to `module foo; export:`)
C) is `main`, or it's called from `main` (in these cases it's
inferred as `export`)
D) is a `unittest`, or called from one (under `version(unittest)`
`unittest`s (and functions they call) are inferred as `export`)
E) is marked as `extern($lang)` or called from such function
(again inferred as `export` in such cases)
F) is virtual, or called from such function (again inferred as
`export` in those cases)
`export` must be a function storage class orthogonal to
protection modifiers, just like `extern`.
Yeah, it will break the world, so this new compilation strategy
should be opt-in via a switch (e.g. `-ix`, `-lazy`,
`--as-needed`, etc.). I suspect it will play nicely with the
existing `-i` ;)
Implications? From top of my head:
1. No need for a new `@cttfe` function attribute, or to treat
`assert(__ctfe)` in special way. Though, on second thoughts,
perhaps it should be an error to have non-conditional
`assert(__ctfe)` inside `export`-ed functions.
2. Regular functions gain some of the special powers of template
ones - specifically, they're codegen-ed only if needed. Before,
to make druntime/phobos functions accessible from DasBetterC we
had to make them templates. Now this awkward technique (what's
the point of having a template with no parameters? Non-template
auto-returning functions also have attribute inference) is no
longer needed.
3. Compilation speed and code bloat are reduced
4. D libraries become kind of like header-only C++ libraries.
5. Until now object files (or static libraries) were a primary
build caching technique. Now a per-function caching technique
would be much more helpful.
More information about the Digitalmars-d
mailing list