Feature Request: Add comptime Functionality Similar to ZigLang to Dart about language

[lrhn]

As mentioned, the difference between macros and comp time is that macros are specified as running as a separate program.
A comp time expression needs to be prevented from using any global non-constant/comptime state.

If a comptime expression, fx, increments a global variable, then it's not valid as a constant. compile-time operations must not have side effects, because those side effects may be important to keeping the result valid.
If a comptime expresssion reads a global variable, then that variable must have a constant value.

Generally, a comptime operation can only invoke other comptime operations, and currently there are none.
We'd have to annotate the platform APIs with operations that are comptime compatible, but in an interface based language, that's not a type-based thing. You can't do for (var i in something) unless all subtypes of the type of something have comptime declared get iterator which return values that are mutable (iterators have mutable state) that are still guaranteed to be comptime compatible, meaning it must not touch global state.

Dart is not designed to make global side effects visible in an API.
Imagine if some class's toString updated a global variable, so you couldn't be allowed to call Object.toString in general. Well, it happens that List.toString does exactly that, it uses a global stack for detecting cycles, also shared with other iterables. Might even be the same one used by jsonEncode.

That code could probably be rewritten to not (re)use a global variable, but ... The alternative would be during the stack in a zone, which is still mutable state external to the function, and blue it's updating Zone._current instead.

Which brings us to async, which is just one big heap of global state. That too could probably be rewritten to be more self-contained, so async computations can be made to run to completion at comptime and not leave lasting changes, but it's not something the API was designed for.

[jakemac53]

We did experiment with what we called "enhanced const", which would expose all the synchronous parts of the language to the const evaluator (basically giving you what you are asking for here but without needing the explicit compliment keyword/annotation, and no async support).

It ends up being quite complicated to support well because of the invalidation semantics that are implied. Any function invoked at compile time invalidates anything that depends on it whenever the body of that function changes, and the same goes for any functions used by that function, etc.

Adding the comptime annotation would assist with that in some ways - making it explicit what is allowed to be used at compile time, and thus which things have the worse invalidation/compilation time behavior. We also considered similar approaches, but determined it would inevitably lead to requests to any sufficiently used package to add @comptime to its functions, and you end up in the same situation.

[scheglov]

It ends up being quite complicated to support well because of the invalidation semantics that are implied. Any function invoked at compile time invalidates anything that depends on it whenever the body of that function changes, and the same goes for any functions used by that function, etc.

To be fair, the same happens for macros too. A macro executes code from its dependencies, so depends not just on API, but on full code. So, the kernel is recompiled on any code change. From this, API of any library that applies a macro depends on full code of the macro and any macro dependencies. So, the analyzer rebuilds element models for libraries with macro applications even if some changes are in function bodies.

Speaking of macros, and the original request of this issue. Macros are already async, and while I think we don't want you to use IO during macros, technically I think it is possible right now :-)

[jakemac53]

The difference with macros is the boundary is more well defined and we expect them to be written less often. If any constant expression could call functions, that would likely get used a ton, and so we would have these invalidation semantics much more often.

[jakemac53]

Speaking of macros, and the original request of this issue. Macros are already async, and while I think we don't want you to use IO during macros, technically I think it is possible right now :-)

It is currently possible I think yes, but it is specified that it is not allowed :). We also don't have the replacement (Resource) API implemented, and it isn't the end of the world if people use dart:io right now, if they are just reading files.