# Proposal: replace @parameter with comptime statement modifier **URL:** \ **Category:** Mojo\ **Created:** [February 11, 2026, 1:59am UTC](https://forum.modular.com/t/proposal-replace-parameter-with-comptime-statement-modifier/2713 "2026-02-11T01:59:27Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![denis](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.modular.com/denis/32/399_2.png) [@denis](https://forum.modular.com/u/denis)\ **Post date:** [February 11, 2026, 1:59am UTC](https://forum.modular.com/t/proposal-replace-parameter-with-comptime-statement-modifier/2713/1 "2026-02-11T01:59:27Z")
Hey all, one more proposed syntax change: deprecate @parameter decorator on `if` and `for` statements and use the `comptime` keyword instead. Here is the proposal document, please take a look and share your thoughts. – Denis > > > modifier > > Add a new proposal describing the plan to replace the \`@parameter\` > dec…orator on \`if\` and \`for\` statements with \`comptime if\` and \`comptime > for\` statement modifiers. Also covers \`comptime assert\` as a replacement > for \`\_\_comptime\_assert\`. > > MODULAR\_ORIG\_COMMIT\_REV\_ID: 3824a234530c974ede9559e2a72b5d4e4dc83993 ---
**Author:** ![christoph\_schlumpf](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.modular.com/christoph_schlumpf/32/274_2.png) [@christoph\_schlumpf](https://forum.modular.com/u/christoph_schlumpf)\ **Post date:** [February 11, 2026, 7:26am UTC](https://forum.modular.com/t/proposal-replace-parameter-with-comptime-statement-modifier/2713/2 "2026-02-11T07:26:17Z")
I like the new syntax and it’s overall consistency compared to the status quo and discussed alternatives. Some small typos: - „appied“ → „applied“ - `var x = comptime(foo()()` → `var x = comptime(foo())` I think it would be helpful to exactly explain in the Mojo doc how `comptime if` and `comptime for` are handled at comptime. ---
**Author:** ![JosephWakeling](https://avatars.discourse-cdn.com/v4/letter/j/c2a13f/32.png) [@JosephWakeling](https://forum.modular.com/u/JosephWakeling)\ **Post date:** [February 11, 2026, 4:29pm UTC](https://forum.modular.com/t/proposal-replace-parameter-with-comptime-statement-modifier/2713/3 "2026-02-11T16:29:24Z")
The change per se is a good one as it makes clearer what is happening and why. The examples (the proposal in general?) seem to focus on performing numerical calculations at compile time and ignore the potential applications for metaprogramming and conditional codegen. Consider e.g. something like: ```mojo fn foo[dtype: DType](x: Scalar[dtype]) -> Scalar[dtype]: comptime if dtype.is_integer(): # do the calculation in a way that's optimized for ints elif dtype.is_floating_point(): # do the calculation in a way that's optimized for floats ``` It’s worth noting that these `comptime` expressions have equivalents in other languages, such as the `static if` and `static foreach` formulations in the D programming language: > **[Static If Condition - Conditional Compilation - D Programming Language](https://dlang.org/spec/version.html#staticif)** > > AssignExpression is implicitly converted to a boolean type, and is evaluated at compile time. The condition is satisfied if it evaluates to true. It is not satisfied if it evaluates to false. | D Programming Language > **[Static Foreach - Conditional Compilation - D Programming Language](https://dlang.org/spec/version.html#staticforeach)** > > static foreach expands its DeclarationBlock or DeclDefs into a series of declarations, each of which may reference any ForeachType symbols declared. | D Programming Language I would recommend Mojo devs examine D’s use of this feature in detail, as it predates C++’s `constexpr`, and has a wide range of application in delivering highly ergonomic compile time metaprogramming. ---
**Author:** ![owenhilyard](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.modular.com/owenhilyard/32/41_2.png) [@owenhilyard](https://forum.modular.com/u/owenhilyard)\ **Post date:** [February 11, 2026, 6:02pm UTC](https://forum.modular.com/t/proposal-replace-parameter-with-comptime-statement-modifier/2713/4 "2026-02-11T18:02:06Z")
One thing I think could be interesting about the `if comptime expr` route is that, provided the compiler guarantees that `if True` and `if False` get folded, you can have an if chain that mixes compile-time and run-time decisions. ex: ```mojo if comptime (simd_width_of[Float32]() == 1): ... elif comptime (simd_width_of[Float32]() >= 8): ... elif parallelism_level() >= 128: ... else: ... # fallback ``` Without that capability, it becomes a bit messy to express this behavior. My hope is that this would simplify the implementation a lot while providing similar benefits as C++'s `consteval` for sub-expressions, since I would expect any compiler to compile-time fold `if True`/`if False` regardless of whether or not the user asks for it. I see the point about `if comptime(tensor.size()) > dyn_size` being slightly confusing, but I also don’t see a way to not have that if we enable comptime for arbitrary subexpressions, which I feel is desirable. I agree that adding new keywords is a bad idea, since I think that road leads to `mpi_distributed_heterogeneous_multi_device_parallel_for`. However, I think that `comptime for` is really a different concept than `for i in comptime(...)` so it deserves its own keyword to reduce confusion but I have no idea what that would be. `comptime assert` also does something very different than `assert comptime(...)` so I think it also deserves some form of unique signifier. ---
**Author:** ![denis](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.modular.com/denis/32/399_2.png) [@denis](https://forum.modular.com/u/denis)\ **Post date:** [February 12, 2026, 5:36pm UTC](https://forum.modular.com/t/proposal-replace-parameter-with-comptime-statement-modifier/2713/5 "2026-02-12T17:36:52Z")
> [@owenhilyard](#): > > ```auto > if comptime (simd_width_of[Float32]() == 1): ... > elif comptime (simd_width_of[Float32]() >= 8): ... > elif parallelism_level() >= 128: ... > else: .. > > ``` This already works. The `comptime` works as a function, so the first and the second conditions are evaluated at comptime, and as you said, the optimizer folds the IFs away. However, if one did this (under the current proposal) > [@owenhilyard](#): > > ```auto > comptime if (simd_width_of[Float32]() == 1): ... > elif (simd_width_of[Float32]() >= 8): ... > elif parallelism_level() >= 128: ... # fails to compile: dynamic condition at comptime > else: .. > > ``` The last condition would error out. I’m of two minds about this. It can be a powerful thing to mix runtime and comptime in one chain, but it also increases the chances of accidental errors, and the workaround is reasonably easy. ---
**Author:** ![JosephWakeling](https://avatars.discourse-cdn.com/v4/letter/j/c2a13f/32.png) [@JosephWakeling](https://forum.modular.com/u/JosephWakeling)\ **Post date:** [February 12, 2026, 7:01pm UTC](https://forum.modular.com/t/proposal-replace-parameter-with-comptime-statement-modifier/2713/6 "2026-02-12T19:01:57Z")
_(Re-edited to restore the original content. I’ll post what was intended to be a response to a later post below.)_ > [@denis](#): > > > [@owenhilyard](#): > > > > ```auto > > comptime if (simd_width_of[Float32]() == 1): ... > > elif (simd_width_of[Float32]() >= 8): ... > > elif parallelism_level() >= 128: ... # fails to compile: dynamic condition at comptime > > else: .. > > > > ``` > > The last condition would error out. Yes, but surely it would be trivial to modify to: ```mojo comptime if (simd_width_of[Float32]() == 1): ... elif (simd_width_of[Float32]() >= 8): ... else: if parallelism_level() >= 128: # should work, and produce the desired effect, no? ... ``` ---
**Author:** ![owenhilyard](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.modular.com/owenhilyard/32/41_2.png) [@owenhilyard](https://forum.modular.com/u/owenhilyard)\ **Post date:** [February 12, 2026, 7:05pm UTC](https://forum.modular.com/t/proposal-replace-parameter-with-comptime-statement-modifier/2713/7 "2026-02-12T19:05:54Z")
I’m not a huge fan of nesting one “logical” chain, ```auto comptime if ...: elif ...: else: if ...: elif ...: ``` However, having issues because of leaving out a `comptime` is probably worse. ---
**Author:** ![JosephWakeling](https://avatars.discourse-cdn.com/v4/letter/j/c2a13f/32.png) [@JosephWakeling](https://forum.modular.com/u/JosephWakeling)\ **Post date:** [February 12, 2026, 8:37pm UTC](https://forum.modular.com/t/proposal-replace-parameter-with-comptime-statement-modifier/2713/8 "2026-02-12T20:37:29Z")
Damn, did I just accidentally edit my previous post instead of creating a new reply? ☹ ---
**Author:** ![JosephWakeling](https://avatars.discourse-cdn.com/v4/letter/j/c2a13f/32.png) [@JosephWakeling](https://forum.modular.com/u/JosephWakeling)\ **Post date:** [February 13, 2026, 10:48am UTC](https://forum.modular.com/t/proposal-replace-parameter-with-comptime-statement-modifier/2713/9 "2026-02-13T10:48:22Z")
> [@owenhilyard](#): > > ```auto > if comptime (simd_width_of[Float32]() == 1): ... > elif comptime (simd_width_of[Float32]() >= 8): ... > elif parallelism_level() >= 128: ... > else: ... # fallback > > ``` As a point of detail … shouldn’t the compiler be able to optimize away that first pair of `if`/`elif` statements at compile time anyway? I’d expect it to be able to take advantage of the `simd_width_of` answer being knowable at compile time regardless of whether the `comptime` keyword is used. > [@owenhilyard](#): > > I’m not a huge fan of nesting one “logical” chain, > > ```auto > comptime if ...: > elif ...: > else: > if ...: > elif ...: > > ``` It does feel like this is a case where Pythonic syntax is maybe a little less elegant than it could be, with the elif in particular kind of getting in the way of explicit clarity. In D this would read something like: ```auto static if (...) { // compile-time ... } else static if (...) { // compile-time ... } else if (...) { // runtime ... } else if (...) { // runtime ... } ``` … but that emerges from the C-like semantics. The the separation between compile-time and runtime clauses above is maybe clearer to understand once you grasp it’s equivalent to: ```auto static if (...) { // compile-time ... } else static if (...) { // compile-time ... } else { // compile-time if (...) { // runtime ... } else if (...) { // runtime ... } } ``` Pythonic syntax forces you into writing something like the latter in Mojo. That may not be an entirely bad thing: at least it makes explicit by indentation level the distinction between which clauses are `comptime` and which aren’t. Curious question: what scope rules does Mojo apply inside control flow statements? I ask because in D an important distinction between runtime and compile-time control flow statements is that the runtime statements create a new scope, whereas the compile-time ones don’t (and there are good reasons for that). ---
**Author:** ![denis](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.modular.com/denis/32/399_2.png) [@denis](https://forum.modular.com/u/denis)\ **Post date:** [February 14, 2026, 1:27am UTC](https://forum.modular.com/t/proposal-replace-parameter-with-comptime-statement-modifier/2713/10 "2026-02-14T01:27:40Z")
> [@JosephWakeling](#): > > what scope rules does Mojo apply inside control flow statements? Mojo is closer to Python in that sense. Each indentation level is a scope, so both comptime and runtime ifs define a new scope. One cannot “conditionally create a variable” using comptime-if. To add to the big picture, Mojo can be understood roughly as 3-phase compile. (1) parsing and type checking, (2) generics instantiation and comptime IF folding, and (3) code generation and code optimization. ---
**Author:** ![JosephWakeling](https://avatars.discourse-cdn.com/v4/letter/j/c2a13f/32.png) [@JosephWakeling](https://forum.modular.com/u/JosephWakeling)\ **Post date:** [February 14, 2026, 2:01am UTC](https://forum.modular.com/t/proposal-replace-parameter-with-comptime-statement-modifier/2713/11 "2026-02-14T02:01:51Z")
> [@denis](#): > > One cannot “conditionally create a variable” using comptime-if. Thanks for clarifying. If you have the time (as I’m sure you’re very busy!), could you help me understand why not? And given that it’s not … (a) is it on the roadmap and (b) what’s the current motivation for `comptime if`? (The feature, not the change of keyword.) `comptime for` I can see a motivation for, as it allows the programmer to explicitly force unrolling of the loop. But if the condition of an `if` statement is resolvable at compile time, I would expect the compiler to optimize it away regardless of whether a `comptime` keyword is present or not, so I’m not understanding the intent here. Apologies if I’m missing something obvious. I’m just very conditioned by my own programming experience to see something like `comptime if` as overwhelmingly a tool for compile time metaprogramming. ---
**Author:** ![denis](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.modular.com/denis/32/399_2.png) [@denis](https://forum.modular.com/u/denis)\ **Post date:** [February 14, 2026, 2:37am UTC](https://forum.modular.com/t/proposal-replace-parameter-with-comptime-statement-modifier/2713/12 "2026-02-14T02:37:42Z")
> [@JosephWakeling](#): > > could you help me understand why not? Mojo is built on the idea that a generic function can be analyzed for correctness (“type-checked”) without substituting specific parameter values. Syntax and semantic analysis happens before the comptime IFs are converted to True/False. Now consider an example like: ```auto fn foo[v: Int](): comptime if v = 2: z = 1 # more code here comptime if v > 0: use(z) ``` Mojo compiler is going to complain that the variable `z` is not assigned before `use(z)` Why? Because it does the semantic analysis before it sees call sites of foo(), before it knows what values `v` is going to have. So the “conditionally create a variable” request can’t work – the condition is not known at the time when the compiler checks the program for correctness. My limited understanding of D language is that it takes the opposite approach: semantic analysis (is the variable available at the time of use) is performed during template instantiation. Thus, variables/fields etc can be created conditionally, based on template parameter values. The upside of D’s approach is that it is more powerful and expressive. The upside of Mojo is that each function can be analyzed independently, in isolation, without expensive whole-program template instantiation phase. This makes the mental model simpler, and also enables near-instant compiler feedback in the IDE (which in practice is very much hindered by our not-yet-debugged LSP server). This is a pretty deep topic, and I’m sure others on the forum can explain it better than I do. – Denis ---
**Author:** ![JosephWakeling](https://avatars.discourse-cdn.com/v4/letter/j/c2a13f/32.png) [@JosephWakeling](https://forum.modular.com/u/JosephWakeling)\ **Post date:** [February 14, 2026, 4:56pm UTC](https://forum.modular.com/t/proposal-replace-parameter-with-comptime-statement-modifier/2713/13 "2026-02-14T16:56:32Z")
> [@denis](#): > > Mojo is built on the idea that a generic function can be analyzed for correctness (“type-checked”) without substituting specific parameter values. Syntax and semantic analysis happens before the comptime IFs are converted to True/False. Thanks, that really helps my understanding. FWIW I think I’d consider D code like your example, where a generic function might try to use a parameter that hasn’t been instantiated, to be an implementation bug – either it should explicitly limit the permitted values to ones that will work, or it should ensure the function call only gets made in circumstances where `z` will have been instantiated. But I get the rationale for why Mojo doesn’t allow it, even in cases where the `comptime` paths wouldn’t cause this issue, e.g.: ```mojo fn foo[v: Int](): comptime if v == 2: z = 1 elif v > 0: z = 3 comptime if v > 0: print(z) # still rejected, even though z will always exist in this scope ``` … and I appreciate the tradeoffs involved in those design decisions. ---
**Author:** ![denis](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.modular.com/denis/32/399_2.png) [@denis](https://forum.modular.com/u/denis)\ **Post date:** [February 20, 2026, 4:25am UTC](https://forum.modular.com/t/proposal-replace-parameter-with-comptime-statement-modifier/2713/14 "2026-02-20T04:25:05Z")
Heads up, the changes were implemented, and in the Mojo nightly, `comptime if`, `comptime for` and `comptime assert` all exist. Eventually Mojo will issue warnings (with fix-its) about `@parameter` decorator. I’m not sure how fast to move on this, should we make the warning pop up right away, or wait for some time. Please share your thoughts. ---
**Author:** ![owenhilyard](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.modular.com/owenhilyard/32/41_2.png) [@owenhilyard](https://forum.modular.com/u/owenhilyard)\ **Post date:** [February 20, 2026, 6:39pm UTC](https://forum.modular.com/t/proposal-replace-parameter-with-comptime-statement-modifier/2713/15 "2026-02-20T18:39:45Z")
A warning that points to the how to use the fixit should be fine as soon as you or the team can make it happen. In my opinion, warnings that come with automated fixes aren’t super disruptive. ---
**Author:** ![denis](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.modular.com/denis/32/399_2.png) [@denis](https://forum.modular.com/u/denis)\ **Post date:** [February 28, 2026, 12:08pm UTC](https://forum.modular.com/t/proposal-replace-parameter-with-comptime-statement-modifier/2713/16 "2026-02-28T12:08:22Z")
The rename is complete, next nightly will have deprecation warning for `@parameter for` and `@parameter if` ---
**Author:** ![system](https://us1.discourse-cdn.com/flex001/uploads/modular/original/1X/2751e0fbdc595a99718b216730957e9db4448cfd.jpeg) [@system](https://forum.modular.com/u/system)\ **Post date:** [March 12, 2026, 2:20am UTC](https://forum.modular.com/t/proposal-replace-parameter-with-comptime-statement-modifier/2713/17 "2026-03-12T02:20:48Z")
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.