Const Trait Counterexamples

2025-08-20T00:00:00+00:00

Hi. I'm the lead for Rust's const traits project group. We hope to stabilize const traits soon, but this is a complex feature with huge amounts of design considerations, and we keep getting the same comments from different people who probably have less familiarity with the feature and its design.</p>

That's quite fair because I can't require everyone to have followed every discussion everywhere. I have followed loads of discussions, so this summarizes some of the counterarguments we've had so far.</p>

If you're interested in the language design for how we plan to allow calling trait methods in const contexts, this should be a good complementary resource to the currently open RFC</a>. You might disagree with parts of this post, though.</p>

Current proposal summary</h2>

Declare a trait as const</code> so you can use it in trait bounds:</p>

const</span> trait</span> PartialEq</span><Rhs: ?Sized = Self> {</span>
</span></span></span>    fn</span> </span>eq</span></span>(</span>&</span>self</span>, other</span>:</span> &</span>Rhs</span>)</span></span></span></span> -></span> bool</span></span></span>;</span>
</span></span></span>    fn</span> </span>ne</span></span>(</span>&</span>self</span>, other</span>:</span> &</span>Rhs</span>)</span></span></span></span> -></span> bool</span></span> </span>{</span> !</span>self</span>.</span>eq</span>(</span>other</span>)</span></span> </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span>
</span>const</span> fn</span> </span>foo</span></span><</span>T:</span> ~</span></span>const</span> PartialEq</span>></span>(</span>x:</span> &</span>T,</span> y:</span> &</span>T</span>)</span></span> -></span> bool</span></span> {</span>
</span></span>    x.</span>eq</span>(</span>y</span>)</span></span>
</span></span></span>}</span></span>
</span></code></pre>
Make impls const</code> so we can satisfy those bounds:</p>
pub</span> struct</span> </span>MyType</span><</span>T></span></span></span></span></span>(</span>T</span>)</span></span>;</span>
</span>
</span>impl</span> </span>const</span> PartialEq</span> for</span> MyType</span><</span>(</span>)</span>></span></span> </span>{</span>
</span></span></span>    fn</span> </span>eq</span></span>(</span>&</span>self</span>, other</span>:</span> &</span>Self</span></span>)</span></span></span></span> -></span> bool</span></span> </span>{</span>
</span></span></span></span></span>        true</span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span>
</span>impl</span> </span>PartialEq for</span></span> MyType</span><</span>u8</span>></span></span> </span>{</span>
</span></span></span>    fn</span> </span>eq</span></span>(</span>&</span>self</span>, other</span>:</span> &</span>Self</span></span>)</span></span></span></span> -></span> bool</span></span> </span>{</span>
</span></span></span></span></span>        self</span>.</span>0</span> ==</span> other.</span>0</span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span>
</span>fn</span> </span>non_const_context</span></span>(</span></span>)</span></span></span></span> </span>{</span>
</span></span></span>    assert!</span>(</span>foo</span>(</span>&</span>MyType(</span>0</span>u8</span></span>)</span></span>,</span> &</span>MyType(</span>0</span>u8</span></span>)</span></span></span>)</span></span></span>)</span></span>;</span>
</span></span></span>    assert!</span>(</span>foo</span>(</span>&</span>MyType(</span>(</span></span>)</span></span></span>)</span></span>,</span> &</span>MyType(</span>(</span></span>)</span></span></span>)</span></span></span>)</span></span></span>)</span></span>;</span>
</span></span></span></span>}</span></span></span>
</span>
</span>const</span> CONST_CONTEXT</span>:</span> (</span></span>)</span></span> =</span>  {</span>
</span></span>    //</span> assert!(foo(&MyType(0u8), &MyType(0u8))); ERRORS
</span></span></span>    assert!</span>(</span>foo</span>(</span>&</span>MyType(</span>(</span></span>)</span></span></span>)</span></span>,</span> &</span>MyType(</span>(</span></span>)</span></span></span>)</span></span></span>)</span></span></span>)</span></span>;</span>
</span></span></span>}</span></span>;</span>
</span></code></pre>
For generic const code, a Destruct</code> trait will be made available (not necessarily included in the first stabilization) to allow the type to be dropped at compile time:</p>
pub</span> const</span> fn</span> </span>callit</span></span><</span>T:</span> ~</span></span>const</span> Destruct,</span> F:</span> ~</span>const</span> FnOnce</span>(</span>&</span>T</span>)</span></span>></span>(</span>x:</span> T,</span> f:</span> F</span>)</span></span> {</span>
</span></span>    f</span>(</span>&</span>x</span>)</span></span>
</span></span></span>}</span></span>
</span></code></pre>
T: Destruct</code> is true for all T</code>, while T: ~const Destruct</code> only holds if the compiler knows its destructor can be run in compile time. (See proposal 4 for more on this)</p>
Meaning of ~const</code></h2>

We use ~const</code> throughout this document but it is feasible to switch this to any other compatible syntax (like [const]</code> or (const)</code>). In fact, the nightly Rust as of writing accepts both T: ~const Trait</code> and T: [const] Trait</code>. I'll stick to ~const</code> for simplicity.</p>
</blockquote>
~const</code> is a modifier on trait bounds. (including super traits, e.g. 

const trait A: ~const B {}</code>) In general, they only need to be proven if you're using them from const contexts. Hence they're also called "maybe-const" or "const-if-const" bounds.</p>
~const</code> bounds on a function are only enforced when you call it. This allows us to instantiate a function in const contexts even if we can't call it:</p>
pub</span> const</span> INSTANTIATE_BUT_NOT_CALL</span>:</span> fn</span>(</span>&</span>MyType<</span>u8</span>></span></span>,</span> &</span>MyType<</span>u8</span>></span></span></span>)</span></span> -></span> bool</span> </span>=</span> {</span>
</span></span>    <</span>MyType<</span>u8</span>></span></span> as</span> PartialEq</span>></span>::</span></span>eq
</span></span></span>}</span></span>;</span>
</span></code></pre>
But note that constness isn't a generic parameter and shouldn't be considered instantiated for each call to a const fn</code>:^{1</sup> If you think about the function foo</code> and pass in a T</code> that does not implement const PartialEq</code>, the constness of foo</code> does not</em> change due to the unsatisfied const predicate - const fn</code> is "always-const" (and not "maybe-const"</nobr>) in a sense that it simply imposes additional constraints if called in const contexts.
1: This particular wrong understanding (specifically, constness as a generic effect parameter which is then "tied" to the constness of the trait bounds) runs into a myriad of issues if you think down the line too hard. I have some thoughts about it but it will probably be in a different post.</span></p>}const</span> A:</span> bool</span> =</span> foo</span>(</span>&</span>MyType(</span>0</span>u8</span></span>)</span></span>,</span> &</span>MyType(</span>0</span>u8</span></span>)</span></span></span>)</span></span>;</span>
</span></code></pre>
The call above errors not because foo</code> becomes non-const when T = MyType<u8></code> - it errors because MyType<u8>: const PartialEq</code> isn't satisfied.</p>
With the current proposal and model, we now explore a few alternatives that Rust team members have thought through, and I will explain why they can't really work.</p>
proposal 1: complicity in implicity</h2>
Why not make ~const</code> the default and use an opt-out for non-const bounds?</em></p>
It is expected that people will write ~const</code> bounds a lot. What if we made T: Trait</code> implicitly const-when-const if it's inside a const item? i.e. making the following work:</p>
const</span> fn</span> </span>foo</span></span><</span>T:</span> Add></span></span>(</span>x</span>:</span> T, y</span>:</span> T</span>)</span></span></span></span> -></span> T</span>::</span></span></span>Output</span> </span>{</span>
</span></span></span>    x +</span> y
</span></span></span></span>}</span></span></span>
</span></code></pre>
Users of non-const trait bounds in const fn</code> will now use an opt-out syntax such as ?const</code>:^{2</sup>
2: note that the original LazyCell</code> source code has the trait bound on the impl</code>. This part is only for illustrating the opt-out bound so we don't get into the nitty gritty yet.</span></p>}
impl</span></span><</span>T, F></span></span></span> LazyCell</span><</span>T, F></span></span> </span>{</span>
</span></span></span>    pub</span> const</span> fn</span> </span>new</span></span>(</span>f</span>:</span> F</span>)</span></span></span></span> -></span> LazyCell<</span>T, F></span></span> </span></span>where</span> F:</span> ?const</span> FnOnce(</span>)</span> -> T </span>{</span>
</span></span></span></span></span>        LazyCell {</span> state:</span> UnsafeCell::</span></span>new(</span>State::</span></span>Uninit(</span>f</span>)</span></span></span>)</span></span> </span>}</span></span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
Why can't this work? The very first drawback this proposal faces is that these things are already possible on stable today:</p>
trait</span> Trait</span> {</span></span>}</span></span></span>
</span>impl</span> </span>Trait for</span></span> () </span>{</span></span>}</span></span></span>
</span>
</span>fn</span> </span>something</span></span>(</span></span>)</span></span></span></span> </span>{</span></span>}</span></span></span>
</span>
</span>const</span> fn</span> </span>foo1</span></span>(</span>x</span>:</span> &</span>dyn Trait</span>)</span></span></span></span> </span>{</span></span>}</span></span></span>
</span>const</span> fn</span> </span>foo2</span></span>(</span>x</span>:</span> &</span>impl Trait</span>)</span></span></span></span> </span>{</span></span>}</span></span></span>
</span>const</span> fn</span> </span>foo3</span></span><</span>T:</span> Trait></span></span>(</span>x</span>:</span> &</span>T</span>)</span></span></span></span> </span>{</span></span>}</span></span></span>
</span>const</span> fn</span> </span>foo4</span></span>(</span>x</span>:</span> fn</span>(</span></span>)</span></span></span></span>)</span></span></span></span> </span>{</span></span>}</span></span></span>
</span>const</span> X:</span> fn</span>(</span></span>)</span></span> =</span> something;</span>
</span>const</span> A:</span> &</span>'static</span> dyn Trait =</span> &</span>(</span></span>)</span></span>;</span>
</span></code></pre>
If we ever wanted to allow impl Trait</code>/dyn Trait</code>/fn()</code> to be callable in const contexts, then they should follow the same opt-out, necessitating the following change:</p>
trait</span> Trait</span> {</span></span>}</span></span></span>
</span>impl</span> </span>Trait for</span></span> () </span>{</span></span>}</span></span></span>
</span>
</span>fn</span> </span>something</span></span>(</span></span>)</span></span></span></span> </span>{</span></span>}</span></span></span>
</span>
</span>const</span> fn</span> </span>foo1</span></span>(</span>x</span>:</span> &</span>dyn ?const</span> Trait</span>)</span></span></span></span> </span>{</span></span>}</span></span></span>
</span>const</span> fn</span> </span>foo2</span></span>(</span>x</span>:</span> &</span>impl ?const</span> Trait</span>)</span></span></span></span> </span>{</span></span>}</span></span></span>
</span>const</span> fn</span> </span>foo3</span></span><</span>T:</span> ?</span></span>const</span> Trait></span>(</span>x:</span> &</span>T</span>)</span></span> {</span></span>}</span></span>
</span>const</span> fn</span> </span>foo4</span></span>(</span>x</span>:</span> ?const</span> fn</span>(</span></span>)</span></span></span></span>)</span></span></span></span> </span>{</span></span>}</span></span></span>
</span>const</span> X:</span> ?</span>const</span> fn</span>(</span></span>)</span></span> =</span> something;</span>
</span>const</span> A:</span> &</span>'static</span> dyn ?</span>const</span> Trait =</span> &</span>(</span></span>)</span></span>;</span>
</span></code></pre>
This then runs into multiple problems.</p>
1A: editioning everything</h3>
We already allow trait bounds that mean non-const in const fn</code>. This means if we were to change T: Trait</code> in const fn</code> to what we currently mean by T: ~const Trait</code>, we have to do it over an edition since it is a breaking change.</p>
But of course we can't make these changes immediately. Suppose we're currently in the 2024 edition and we accept this plan to migrate everyone to use ?const</code> where necessary. We can accept ?const</code> in any edition as it is equivalent to T: Trait</code> now. Now in 2026 edition we deprecate non-?const</code> bounds, we emit a warning everytime someone writes T: Trait</code> but means T: ?const Trait</code>. In 2028 edition T: Trait</code> now means T: ~const Trait</code> (implicit behavior). We need to do this change over two editions because just doing it in one edition is even more problematic.</p>
Suppose FnOnce</code> becomes a const trait. This poses issues for crates in edition 2024 or below, who have written this:</p>
pub</span> struct</span> </span>MyWrapper</span><</span>F></span></span></span></span></span>(</span>F</span>)</span></span>;</span>
</span>
</span>impl</span></span><</span>F></span></span></span> MyWrapper</span><</span>F></span></span> </span>{</span>
</span></span></span>    const</span> fn</span> </span>new</span></span>(</span>f</span>:</span> F</span>)</span></span></span></span> -></span> Self</span> </span></span>where</span> F:</span> FnOnce(</span>)</span> </span>{</span>
</span></span></span></span></span>        MyWrapper(</span>f</span>)</span></span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
It is dangerous for crates having non-const bounds that never went through the intermediate 2026 edition to directly migrate to edition 2028, as edition migration processes primarily rely on things compilers can catch. There are things that cargo fix --edition</code> can't catch, and there are people who upgrade editions by simply bumping the number and fixing the issues that arise with bumping (how can you fault them? I personally never thought editions could significantly change behavior and meaning of syntax).</p>
This is a major meaning change (perhaps bigger than disjoint closure capture</a> and if-let rescope</a> which won't break/change too much) because there are tons of const fn</code> with trait bounds that all currently mean non-const.^{3</sup> Their migration path to a potential 2028 edition is very scary to me.
3: See}this search</a>, and to a lesser extent, this search</a></span></p>
1B: non const traits and implicit bounds</h3>
trait</span> NonConstTrait</span> {</span></span>}</span></span></span>
</span>
</span>const</span> fn</span> </span>foo</span></span><</span>T:</span> NonConstTrait></span></span>(</span></span>)</span></span></span></span> </span>{</span></span>}</span></span></span>
</span></code></pre>
On the outset, there appears to be three choices:</p>

Compile this, with T: NonConstTrait</code> conditionally const</li>
Compile this, but T: NonConstTrait</code> doesn't become conditionally const (not ~const NonConstTrait</code>)</li>
Make this a compile error.</li>
</ol>
#1 can't really work due to breaking change complications when methods change their bounds to ~const</code> (see 2A),
#2 can't work either because it would make it a breaking change for someone to change their trait into a const trait (the T: NonConstTrait</code> becomes stricter if NonConstTrait</code> betrays its name and becomes const</code>)</p>
So the only viable choice is #3. However, this has the ability to confuse many people, specifically with 1C and 1D.</p>
1C: impl confusion</h3>
Should impl</code> blocks also be a part of this elision? That is, should the following have a non-const</nobr> T: Trait</code> bound applied to foo</code> but ~const</code> bound applied to bar</code>?</p>
impl</span></span><</span>T:</span> Trait></span></span></span> MyType</span><</span>T></span></span> </span>{</span>
</span></span></span>    fn</span> </span>foo</span></span>(</span>self</span>, x</span>:</span> T</span>)</span></span></span></span> </span>{</span></span>}</span></span></span>
</span></span></span>    const</span> fn</span> </span>bar</span></span>(</span>self</span>, x</span>:</span> T</span>)</span></span></span></span> </span>{</span></span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
If yes, this can be super confusing. 1B will turn this into an error on bar</code> if Trait</code> is not a const trait. It's also a candidate for accidentally stricter bounds than necessary (when will users know when to use ?const</code>? cc 1D)</p>
If not, it can also be super confusing. The rules for when T: Trait</code> implicitly means T: ~const Trait</code> would be complicated, hard to teach, and slightly inconsistent, given that something like the following should</em> have implicit ~const</code> at the impl-level.</p>
impl</span></span><</span>T:</span> Trait></span></span></span> const</span> Trait</span> for</span> MyType</span><</span>T></span></span> </span>{</span></span>}</span></span></span>
</span></code></pre>
All of this is mostly because of the weird double meaning of T: Trait</code> (on non-const contexts, equivalent to T: ?const Trait</code> in const contexts, but ~const</code> in const-contexts</nobr>)</p>
An explicit opt-in scheme, with ~const</code> bounds at the impl</code> level, if allowed, would not have the same issues, as it is clear what the user intended, and it is clear that it would apply to const fn</code>s.</p>
1D: usage path</h3>
Proposal 1 will make writing stricter bounds the default, as T: Trait</code> in const fn</code> is stricter than T: ?const Trait</code>. It is only with non-const traits (1B) where a user will be prompted to use ?const</code>.</p>
This is a broad assumption that users will most of the times want ~const</code>, similar to Sized</code> vs. ?Sized</code>, but probably less correct than the latter. There are many constructors with trait bounds (e.g. LazyLock</code> with F: FnOnce</code>) that don't need to call methods at compile time. They can be
intended for storage (so the stored types' methods can later be called at runtime), or just using traits' associated consts.</p>
On the other hand, ~const</code> as opt-in would be required only when someone attempts to call a trait's methods (easily suggestable by compiler errors), which would leave people more naturally using T: Trait</code> to mean non-const if they don't need ~const</code>.</p>
1E: virality</h3>
Remember the snippet at the beginning of this proposal which contained function pointers and dyn traits, and impl traits? Well.. about those.</p>
Suppose in the future we might want to allow dyn ~const Trait</code> or ~const fn()</code> pointers. Notwithstanding the potential complexity for the compiler to support these, but let's say struct A(pub ~const fn())</code> is possible, and it means that the field must be a function pointer callable at compile time if A</code> is being constructed at compile time. dyn ~const Trait</code> operates similarly.</p>
This then means an implicit ~const</code> version now has to either (1) affect all types containing fn()</code> pointers and dyn Trait</code>s by making them imply ~const</code> or (2) create an opt-in syntax specifically for these things.</p>
(1) is self-evidently problematic; (2) feels extremely inconsistent, why use opt-in in some places but opt-out in others?</p>
proposal 2: selectiveness</h2>
Why have const apply to the entire trait?</em></p>
This has many layers to unwrap: why do we have to mark the trait at all? Can we have per-method</nobr> choices? Can we do refinement with bounds on specific methods?</p>
We'll answer these in this section, but we'll start with the most general fact: If we want impl</code>s to be const</code> or non-const, there must be a way to distinguish a trait that allows const implementations and a trait that does not. And all current traits (before const traits stabilize) must not allow const implementations.</p>
2A: Which Gender Is Your Trait</h3>
Let's look at Iterator::sum</code></a>:</p>
trait</span> Iterator</span> {</span>
</span></span></span>    type</span> Item</span>;</span>
</span></span></span>    fn</span> </span>sum</span></span><</span>S></span></span>(</span>self</span></span>)</span></span></span></span> -></span> S
</span></span></span></span></span>    </span></span>where</span>
</span></span></span></span>        Self</span>:</span> Sized,
</span></span></span></span>        S:</span> Sum<</span>Self</span>::</span></span></span>Item></span></span>,
</span></span></span></span>    </span>{</span>
</span></span></span></span></span>        Sum::</span></span>sum(</span>self</span></span>)</span></span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
For any generic parameter T</code> where T: ~const Iterator</code>, we can't really call T::sum::<usize></code>. Right now the bound on S</code> is S: Sum<Self::Item></code> but it should really be S: ~const Sum<Self::Item></code>. If we allowed calling T::sum::<usize></code>, and the bound later turns ~const</code>, it would break if usize</code> remains having a non-const Sum</code> impl. So to avoid breaking changes we have two choices:</p>

Allow T: ~const Trait</code> on non-const traits but can't call any of the methods</li>
Disallow T: ~const Trait</code> on non-const traits.</li>
</ol>
Our current design uses #2, as #1 feels quite counterintuitive: the idea of ~const</code> bounds is to allow calling methods on them, so it isn't really useful. It would also prevent any actual uses of generic items with ~const</code> bounds on non-const traits, as const</code> impl</code>s cannot be written without the trait being const</code>. With #2, we're able to give trait authors one</em> chance to make sure their bounds are either non-const or ~const</code> as they see fit. As once the trait is const</code>, turning existing non-const bounds into ~const</code> would be a breaking chnage.</p>
In any case, the compiler must know what is a const trait</code> and what is not.</p>
2B: the constness divide</h3>
The alternative here would be to allow ~const Tr</code> bounds on Tr</code> without it being marked a const trait, but not allow calls to methods until the methods are marked const in some way. (i.e. per-method constness)</p>
trait</span> A</span> {</span>
</span></span></span>    ~</span>const</span> fn</span> </span>foo</span></span>(</span></span>)</span></span></span></span> </span>{</span></span>}</span></span></span>
</span></span></span>    fn</span> </span>bar</span></span>(</span></span>)</span></span></span></span> </span>{</span></span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span>
</span>const</span> fn</span> </span>uwu</span></span><</span>T:</span> ~</span></span>const</span> A></span>(</span></span>)</span></span> {</span>
</span></span>    T::</span></span>foo(</span></span>)</span></span>;</span> //</span> can be used
</span></span></span>    //</span> T::bar(); errors
</span></span></span></span>}</span></span>
</span></code></pre>
This has its own caveats.</p>
First, this means there are never-const methods in a trait. Some methods allow callers in const contexts and require const implementations while some do not. I don't think that's really useful. If a user writes T: ~const Trait</code>, they'd normally expect every method in Trait</code> to now be const-callable. It's quite rare for a trait to be designed in a way that allows some methods to be callable in const contexts while others not. (at least, no one has ever provided a concrete example) Those use cases would be covered by separating them into two traits anyways.</p>
Second, we still</em> need a way to figure out whether a trait is const</code> to decide whether to allow const</code> impl</code>s. We can't allow const</code> impl</code>s for non-const traits, to allow existing non-const traits to transition their methods into const.</p>
But that means once A</code> makes foo</code> ~const</code> and publishes a new crate version, they've lost their ability to make bar</code> ~const</code> in the future, as downstream crates would happily do this:</p>
impl</span> </span>const</span> A</span> for</span> MyType</span> </span>{</span>
</span></span></span>    const</span> fn</span> </span>foo</span></span>(</span></span>)</span></span></span></span> </span>{</span></span>}</span></span></span>
</span></span></span>    fn</span> </span>bar</span></span>(</span></span>)</span></span></span></span> </span>{</span> println!</span>(</span></span>"</span>some non-const operation"</span></span></span>)</span></span> </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
That is super awkward to both teach and learn. This awkwardness was even more extensively discussed in my HackMD doc</a> from four months ago.</p>
2C: per-method bounds</h3>
Okay, so, it's really awkward for fine-grained per-method constness to co-exist with whole-trait constness (necessary for trait bounds as well as whether to allow const</code> impl</code>s). What if we dealt away with whole-trait constness entirely?</p>
Consider ~const</code> bounds on methods. Some scheme like:</p>
const</span> fn</span> </span>foo</span></span><</span>T:</span> PartialEq</span>></span></span>(</span>x</span>:</span> &</span>T, y</span>:</span> &</span>T</span>)</span></span></span></span> -></span> bool</span> </span></span>where</span> T</span>::</span></span></span>eq:</span> ~const</span> </span>{</span>
</span></span></span>    x.</span>eq</span>(</span>y</span>)</span></span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
Where impl</code>s can't be wholly const</code> or non-const, but individual methods can become const</code> on their own:</p>
trait</span> B</span> {</span>
</span></span></span>    fn</span> </span>owo</span></span>(</span></span>)</span></span></span></span>;</span>
</span></span></span></span>}</span></span></span>
</span>
</span>impl</span> </span>B for</span></span> () </span>{</span>
</span></span></span>     const</span> fn</span> </span>owo</span></span>(</span></span>)</span></span></span></span> </span>{</span></span>}</span></span></span> //</span> now possible
</span></span></span></span></span>}</span></span></span>
</span></code></pre>
But that proposal has a lot</em> of downsides.</p>
Because all methods' signatures are now lying to you. Consider the common case of some impl using a generic type's methods:</p>
trait</span> C</span> {</span>
</span></span></span>    fn</span> </span>some_fun_method</span></span>(</span></span>)</span></span></span></span>;</span>
</span></span></span></span>}</span></span></span>
</span>
</span>impl</span></span><</span>T:</span> C></span></span></span> C for</span></span> Option</span><</span>T></span></span> </span>{</span>
</span></span></span>    const</span> fn</span> </span>some_fun_method</span></span>(</span></span>)</span></span></span></span> /*</span> where T::some_fun_method: ~const */</span></span> </span>{</span>
</span></span></span></span></span>        //</span> T::some_fun_method()
</span></span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
in Option<T>::some_fun_method</code>, we have no idea whether we can actually call T::some_fun_method</code>, without writing a bound. Making this bound apply to the entire trait impl seems awful to require (defeats the entire point of an individual method being const</code> and writing ~const</code> bounds on individual methods), so then this per-method bound now applies to some_fun_method</code>. That also means the requirements for a particular method to be const</code> may be stricter than what is written on the trait method signature. (C::some_fun_method</code> has no additional restrictions whereas <Option<T> as C>::some_fun_method</code> does).</p>
This is pretty much not avoidable, as traits upstream cannot know what methods downstream impls want to call (in this case, T</code> is not even nameable at the upstream trait C</code>)</p>
Therefore, all const fns that attempt to call some trait methods on a generic parameter must add a bound on that specific method.</p>
This is particularly frustrating for Iterator</code>, which has loads of extension methods (that can all be overriden to do something non-const, under this scheme), and bounds are necessary for all methods being called, resulting in the following for a function that should have been super simple:</p>
const</span> fn</span> </span>sum_double</span></span><</span>I></span></span>(</span>i</span>:</span> I</span>)</span></span></span></span> -></span> u32</span>
</span></span></span></span></span>where</span>
</span></span>    I:</span> IntoIterator</span><</span>Item = u32</span>></span></span>,
</span></span>    I</span>::</span></span></span>into_iter:</span> ~const</span>,
</span></span>    <</span>I</span>::</span></span></span>IntoIter as</span> Iterator</span>></span></span>::</span></span>map:</span> ~const</span>,
</span></span>    <</span>Map<</span>I</span>::</span></span></span>IntoIter, const</span> fn</span>(</span></span>u32</span>)</span></span></span> -></span> u32</span></span>></span></span>></span></span>::</span></span>sum::</span></span><</span>u32</span>></span></span>:</span> ~const</span>,
</span></span></span>{</span>
</span></span></span>    const</span> fn</span> </span>double</span></span>(</span>x</span>:</span> u32</span></span>)</span></span></span></span> -></span> u32</span></span> </span>{</span> x*</span>2</span> </span>}</span></span></span>
</span></span></span>    i.</span>into_iter</span>(</span></span>)</span></span>.</span>map</span>(</span>double</span>)</span></span>.</span>sum</span>(</span></span>)</span></span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
This proposal might also need special annotations on trait methods that provide a const</code> default method body but otherwise doesn't require downstream impl</code>s to be const</code> (otherwise you wouldn't know which default method bodies are callable from const</code>). That adds an additional layer of syntax complexity which needs to be designed.</p>
There was also a bit of Zulip discussion on this. See this topic</a> and its discussion, mainly before May 8th.</p>
proposal 3: isn't it just const</code>?</h2>
Why not use T: const Trait</code> for const-when-const bounds?</em></p>
This is one of the proposals which actually has some</em> merit. The idea is to use T: const Trait</code> for the "const-if-const" syntax, while thinking about the future with const(always)</code> or =const</code> to represent always-const bounds.</p>
Because it turns out we actually do need always-const bounds, for the trait bound to be used in an assoc const-item const A: () = ();</code>, in a const block const { 1 + 2 }</code>, or in const generic arguments [T; { 1 + 2 }]</code>. Those could become usage sites that require a stricter bound than ~const</code>, so we must think about reserving the "always-const" bound for them.</p>
My main reservation with this proposal is that it sort of justifies a change of const items, const blocks into using the same new syntax for always-const bounds. so const(always) X: i32 = 42;</code> and const(always) { 2 * 3 * 7 }</code> instead of what we have now which reserves T: const Trait</code> for always-const to keep the consistency. But we always have some</em> form of (small, potentially acceptable) inconsistency one way or the other (such as ~const</code> in const fn</code>, see proposal 6), so it might end up being an option we end up choosing.</p>
proposal 4: destructive interference</h2>
Why Destruct</code>? Why not just T: ~const Drop</code>?</em></p>
We are in a special place because some destructors are non-const. We already allow non-const</nobr> impl Drop for MyType</code>s, so there needs to be a way to distinguish types that can be dropped in compile time from types that cannot.</p>
This leads to us to a new marker trait called Destruct</code>, which is automatically implemented. Non-const Destruct</code> holds for all types, but const Destruct</code> only holds if the type's Drop</code> impl (if it exists) is const and the type's components all implement const Destruct</code>.</p>
Therefore, you must sprinkle your functions with T: ~const Destruct</code> bounds when you're constifying them, if generic parameters need to be dropped at any point in the function.</p>
Why not T: ~const Drop</code>? Well it makes a huge asymmetry with T: Drop</code> bounds, as the latter would only hold if T</code> has a manual Drop</code> impl. It would also make T: const Drop</code> not imply T: Drop</code>, which has weird language-level implications as well as compiler-level implications. (we have run into trait bound cache issues with this in the past^{4</sup>)
4: it might</em> be fine to desugar T: ~const Drop</code> into T: ~const Destruct</code> while keeping Destruct</code> hidden. I still don't think that's a good option because of the asymmetry.</span></p>}T: Drop</code> is also a valid bound even though you might not have seen this. pin-project</code> uses</a> this bound to prevent any user from writing their own custom destructors on their types. So no matter what scheme we end up choosing, we must</em> have at least two traits. One to represent the ability to be destructed, one to represent whether or not a type has a custom destructor. Otherwise we run into asymmetry between T: const Drop</code> vs T: Drop</code>.</p>
proposal 4.5: destructive interference, part 2</h2>
Can we make T: ~const Destruct</code> implicit?</em></p>
This is hard to say, depending on what is meant by "implicit". Inferring whether requiring ~const Destruct</code> for generic types based on whether the code has a possibility to drop the type is no-go, because changing the type signature/trait bounds based on the body has loads of bad semver complications and is generally not possible in the compiler architecture.</p>
Making ~const Destruct</code> implicit for all generic params is not good, either. Many generic API interfaces want to assume as little about their types as possible, so a broad scheme like this necessitates an opt-out syntax which seems too odd to have/hard to design.</p>
A more limited plan might be to infer a : ~const Destruct</code> super trait if some methods on a trait take self</code> by-value, that also has issues because the following example means shouldn't have const trait Add: ~const Destruct</code> inferred:</p>
#!</span>[</span>feature</span>(</span></span></span>const_ops</span></span>)</span></span></span>]</span></span>
</span>#!</span>[</span>feature</span>(</span></span></span>const_trait_impl</span></span>)</span></span></span>]</span></span>
</span>#!</span>[</span>feature</span>(</span></span></span>const_precise_live_drops</span></span>)</span></span></span>]</span></span>
</span>
</span>use</span> std::</span></span>ops::</span></span>Add;</span>
</span>
</span>pub</span> struct</span> </span>Wrapper</span><</span>T></span></span></span></span></span>(</span>T</span>)</span></span>;</span>
</span>
</span>impl</span></span><</span>T:</span> ~</span></span></span>const</span> Add</span>> const</span> Add</span><</span>Wrapper<</span>T></span></span>></span></span> for</span> Wrapper</span><</span>T></span></span> </span>{</span>
</span></span></span>    type</span> Output</span> =</span> Wrapper<</span>T</span>::</span></span></span>Output></span></span>;</span>
</span></span></span>    fn</span> </span>add</span></span>(</span>self</span>, other</span>:</span> Self</span></span>)</span></span></span></span> -></span> Self</span>::</span></span></span>Output</span> </span>{</span>
</span></span></span></span></span>        Wrapper(</span>self</span>.</span>0</span> +</span> other.</span>0</span></span>)</span></span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
One possible plan (will likely be our actual plan) is to lint const traits that take self</code> by-value and recommend adding a ~const Destruct</code> super trait. That way it will save crate users relying on that trait to not have to add ~const Destruct</code> bounds everywhere, at the same time not assuming everyone wants this.</p>
proposal 5: academic zealotry</h2>
Let's follow the approach used in academic paper X..</em></p>
This section was adapted from a similar comment I made on Zulip</a> in May.</p>
Academic research is exciting work. Language design in Rust is different (maybe slightly boring?) because it's mostly a weighing of the pros and cons of every possible alternatives and finding ways to practically make the language more capable.</p>
The work on const traits in Rust is often linked to work on effects in other (academic) programming languages, results published via research papers, etc.</p>
We then often see an excitement to apply those academic thinking models to Rust.</p>
Those thinking models often appear super convoluted to me. It sometimes looks like practicality has been dismissed in favor of generality. That's fine, but I don't think they are very compatible with Rust.</p>
I think it would be fair to consider the role of formal modeling of effects as a different programming language and how programmers using that programming language model their functions and their ability to be called in different contexts. (i.e. runtime vs. compile time)</p>
The academic way of thinking about effects/const traits holds the same amount of weight as some other programming language's way of thinking about effects/const traits to me. It's nice to try to incorporate the bits that would work for us, but incompatible things are incompatible. Forcing Rust's model to be losslessly transferable to a formal model is equivalent to forcing Rust's model to be losslessly transferable to a different programming language, say Zig. We can't assume that ideas about programming languages suddenly become applicable to all programming languages just because those ideas are published to a peer-reviewed journal. Our RFCs are always peer-reviewed, too.</p>
It is cool to think about effects or capabilities and how we can encode them as modifiers to entities in the type system, be it traits, trait bounds, functions, impls, etc. We're not in the best place to unify them because const</code> is the inverse of an effect (it prevents you from calling non-const items) while async</code> is an actual effect (it allows you to call other async</code> items). At the same time const</code> seems like it wants to apply to the whole trait, while partial maybe-async</code> traits seem very desirable.</p>
If we wanted to unify them to make our version of effects closer to formal modeling, we must do so for everything that we currently have, not just const traits. So we should also think about whether it is really feasible</em> to do so in the first place, and then decide whether or not we can proceed with a stabilization of const traits with the pieces that make the most sense for the language right now</em>, without having to make our effects story consistent first.</p>
proposal 6: drowning in conditionals</h2>
We should have ~const fn</code> and ~const trait</code> and impl ~const</code>, etc.</em></p>
The idea here is that ~const</code> is "conditionally const", i.e. may or may not require const impls depending on whether called from a const context. Given that const fn</code> is also "maybe-const" (i.e. could be called from both non-const and const contexts), we should make them also use ~const</code>, like ~const fn</code> for consistency and also distinguish with const X: () = ();</code> items.</p>
My biggest feeling here is that it changes up everything for no gain. I think rarely anyone benefits from this. It might feel consistent but I'd rather not let us be consistent for consistent's sake.</p>
But still, there are other consistency arguments that contradict this. const fn</code>, const trait</code>, and impl const</code>, and const items/const blocks all restrict their bodies to operations performable in compile time, i.e. they must all call const fn</code>s. In terms of restriction they work mostly the same except for which trait's methods they can call (in const fn</code> you can call methods from T: ~const Tr</code> but in const</code> items you can't)</p>
Also, it makes little sense to have an "always-const" fn such that it cannot be called in non-const</nobr> fns. But that's what ~const fn</code> seems to imply exists.</p>
The other idea here relates to the "meaning of ~const</code>" section. The constness of the fn</code> never changes. It should always be evaluatable at compile time. But when you pass in some T</code> into const fn foo<T: ~const Tr></code> that doesn't impl const Tr</code>, and try to call it from compile time, it's not that foo</code> now is non-const (foo</code> is fully prepared to be evaluated in compile time) but that you aren't satisfying foo</code>'s constraints.</p>
proposal 7: questionable conditions</h2>
?const</code> is okay for "maybe-const".. right?</em></p>
We have received proposals like this because ~const</code> introduces a new sigil, and the alternatives don't seem to be as good. Why don't we use T: ?const Trait</code> to mean T: ~const Trait</code>?</p>
The main reason here is that ?</code> has an existing meaning in trait-bound adjacent areas, which is to relax</em> a bound, or to disable</em> a default, such as ?Sized</code>. T: ~const Trait</code> is a stricter bound than T: Trait</code>, so using ?</code> for it isn't really nice. This is also the reason proposal 1 (and the ancient implementation before it got switched due to issues aforementioned) uses ?const</code> for opt-out.</p>
Using ?const</code> for opt-in, on the other hand, isn't a good syntax proposal.</p>
let's try picking wavelengths for these sheds..</h2>
These are things we should actually try to form consensus on before stabilizing:</p>

Syntax of the const-when-const bounds. There's ~const</code> and [const]</code> and (const)</code>

We can figure this out along with possibility of proposal 3 (~const</code> => const</code>, const</code> => =const</code> or other) on the table.</li>
</ul>
</li>
Order of keywords - whether to use const impl Trait for Ty</code> or impl const Trait for Ty</code>

Had some discussion on the RFC PR</a> recently.</li>
</ul>
</li>
Naming of Destruct</code>

Not really discussed anywhere, but we might want to find a better name for Destruct</code> if we want to stabilize it. Droppable</code>? Destroy</code>?</li>
</ul>
</li>
</ul>
Save this for the future</h2>
These are some features that are not</em> essential for const traits. Including them will unnecessarily enlarge the scope
of the RFC. But it might still be useful to propose them later.</p>

const fn</code> trait methods - where downstream has to implement as const fn</code> no matter whether impl</code> is const or not.</li>
~const fn</code> pointers, dyn ~const Trait</code>, impl ~const Trait</code></li>
Figuring out something for the "really const" distinction (related to proposal 6), if that is really worth it - what
we should do with const {}</code> blocks and const X: Ty = ...</code> items.</li>
Figuring out a way to configure derives (built-in or custom) to generate const implementations.

Although we might still want to recommend a way for custom derives to start generating const impls.</li>
</ul>
</li>
</ul>
So, what's next?</h2>
I started my work on const traits on July 1st, 2021</a>, making it so that
const trait impls can be called across different crates. I've worked on the implementation of this feature since then,
and now it's been four years.</p>
We might still have many years to go, but hopefully this post helps making the language design discourse better.</p>
If you would like to get involved, feel free to go comment on the open RFC</a> (please comment on specific lines or on
the file using the PR review feature, this makes discussion threaded and much easier to follow), or follow discussions
occuring on the #t-lang/effects</a> Zulip channel.</p>
I suppose you can also consider supporting me on GitHub Sponsors</a> :D</p>
Acknowledgements</h2>

Thanks errs</a> for the encouragement to write this post, and oli</a> for commenting on initial drafts of the proposal and providing more thinking on Proposal 4 and 4.5.</li>
</ul>

Devlog 002

2025-06-09T00:00:00+00:00

Hi y'all! It's been a while</a> since I've done a devlog, and I figured it's time to share a bunch of things I have worked on, just to celebrate what I've done and take some time to reflect on what I could do next.</p>

Let's get into it!</p>

Rust related stuff</h2>

Const Traits</h3>
I've been working on this feature for almost four years</a> now, and the feature is only recently getting some momentum towards finally being accepted. Oli</a> opened a new RFC</a> which drew a lot of commentary and the lang team seems ready to accept, though only after we figure out how the syntax works. There's a lot of design work, which includes debating the syntax and finding reasons why one color for the shed works better than the other, which is happening at the #t-lang/effects Zulip channel</a>. I tried to articulate reasons for the colors I prefer, and I was moderately successful in convincing the lang team into adopting some of the choice.</p>
I'm actually hoping that const traits can get stabilized this year, given the amount of time and effort everyone is putting in to polish the language design into completion. I'm glad that I was able to help (even though errs</a> did a really fantastic job of figuring out the compiler architecture to make the thing robust and easy to develop) on the compiler side to push things to a stable and well-tested state.</p>

Frontmatters</h3>
This</a> was a particularly cool PR because I think I like working on the compiler frontend. The backstory to that, though, was that I gave a lot of pedantic reviews in the original PR and made epage</a>, the original author who drafted an implementation, quite annoyed at me. But at the same time, I wanted to ensure that the compiler has a solid quality code to work off of, especially when it comes to initial implementations of a feature. So I offered to implement it. It wasn't too bad because it wasn't my first time working on the lexer/parser part of the frontend, with my experience implementing c-str literals</a>. Mapping out all the possible error cases and how best to handle them did take some time though. It was a nice learning experience nonetheless.</p>

Reviews</h3>
I really like spending time to review PRs. At time of writing, I have 272 reviewed PRs</a> that have been merged into rust-lang/rust. I'm also sometimes really nitpicky when it comes to reviews. I think it is good to point out things that the other person may have not noticed instead of silently accepting, and it is also good to hear from different perspectives whether I am a reviewer or a PR author. I want to do more reviews and if I get bored I might steal some.</p>

AST visitor stuff</h3>

I'm trying to deduplicate the AST Visitor</code> and MutVisitor</code> functions in rustc. The work is currently tracked at#127615</a>, and it's mostly an exercise for me to get back at developing rustc in my free time. I've done some really clever stuff in the mean time:</p>

Visitor</code> is allowed to return a ControlFlow</code> while visiting stuff, this is controlled by the implementer's choice when impl</code>ing Visitor</code> and setting the Result</code> associated type to ControlFlow</code> instead of the ()</code> by default.</p>

MutVisitor</code> does not allow returning ControlFlow</code>s and only allows returning ()</code>s. This creates some hassle while writing the macro that emits functions for both visitors. My first solution to this is to use something like the following:</p>

fn</span> </span>visit_id</span></span><</span>$(</span>$lt</span>,)</span>?</span></span> V:</span> $Visitor</span>$</span>(</span><</span>$lt</span>></span></span>)</span></span>?</span>></span>(</span>vis:</span> &</span>mut</span> V,</span> id:</span> &</span>$</span>(</span>$lt</span></span>)</span></span>?</span> $</span>(</span>$mut</span></span>)</span></span>?</span> NodeId</span>)</span></span> $</span>(</span>-></span> <</span>V as</span> Visitor<</span>$lt</span>></span></span>></span></span>::</span></span>Result</span></span>)</span></span>?</span> {</span>
</span></span>    /*</span> implementation goes here */</span></span>
</span></span></span>}</span></span>
</span></code></pre>
Although trivially copyable, it has a lot of characters and served as an extra step when converting from the normal
V::Result</code>. I then decided to use a sealed super trait trick in my latest PR</a>:</p>
mod</span> sealed</span> {</span>
</span></span></span>    use</span> rustc_ast_ir::</span></span>visit::</span></span>VisitorResult;</span>
</span></span></span>
</span></span></span>    ///</span> This is for compatibility with the regular `Visitor`.
</span></span></span></span>    pub</span> trait</span> MutVisitorResult</span> {</span>
</span></span></span></span></span>        type</span> Result</span>:</span> VisitorResult;</span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span>
</span></span></span>    impl</span></span><</span>T></span></span></span> MutVisitorResult for</span></span> T</span> </span>{</span>
</span></span></span></span></span>        type</span> Result</span> =</span> (</span></span>)</span></span>;</span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span>
</span>use</span> sealed::</span></span>MutVisitorResult;</span>
</span>
</span>pub</span> trait</span> MutVisitor</span>: Sized + MutVisitorResult<Result = ()> {</span>
</span></span></span>    /*</span> methods go here */</span></span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
Then, we can use V::Result</code> however we like, and</em> it is a drop-in replacement because we know</em> that it is always
going to be ()</code>. Really proud of myself for this one.</p>
Wikimedia related stuff</h2>
WikiAuthBot-ng</h3>
This</a> is a bot that uses OAuth to connect users on Discord to their
identity on Wikipedia. Some Wikipedia-related servers require people to authenticate to talk, while others want to use
it to allow easy querying of identity from Discord.</p>
The original version (WikiAuthBot) was written in Python and had a lot of bugs. I rewrote it in Rust and added a lot of
additional functionalities. Working with databases stood out particularly in my process in making this a completed,
stable project. I first went with using the provided MariaDB instance on Toolforge</a>, then I thought it was too slow and
switched to using Redis as a persistent storage. Then I thought it was too slow again and I tried SQLite. But Toolforge
uses NFS for all hosted projects and SQLite is known to not work as optimally via NFS. I then went back to MariaDB and
it got fast again. All of these involved writing small Rust code that translated data from one place to the other, which
was quite some hassle.</p>
In the end though it worked out.</p>
DeadbeefBot</h3>
This</a> was yet another project. It's tasks can be found on its
Wikipedia page</a>, but it essentially helps maintain some formatting of Wikipedia pages. The code was not too hard and I
worked on its design quite some time already, but it took some procrastinating for me to actually get this registered as
a cron job. But I got there in the end.</p>
w</code></h3>
Yeah, it's another MediaWiki API library</a>. I originally wanted to use the name mw</code>
seeing that it wasn't used at the time, but it got taken by a different</a> crate. I talked
to the person who took that name and they refused to give it to me. Luckily the even shorter name w</code> was available, so
yay!</p>
w</code> wants to be minimal because it doesn't want to make assumptions about how one should use it. My previous library was
a failure as I was too ambitious in wanting to represent all possible API combinations into types (turns out it's so
huge and messy, and in the end I would've only done the request part only anyways). So I decided to push that onto the
users. Users should decide how to serialize their requests and deserialize their responses.</p>
mwapi</code></a> was a similar library, but my submissiveness to capitalism pushed me towards wanting a less restrictive
license than GPL, and also because I can't easily work on multiple wiki instances at the same time</a>. The latter feature
was really needed for WikiAuthBot-ng as it needs to work with Wikipedia servers in many different languages (so
different API instances).</p>
I hope I can polish it so that it is more ready for general use. I am satisfied about it enough to use it in my new
projects and I will add to it as I find missing features while using.</p>
Script syncing bot</h3>
This</a> was my solution to a long-running problem on Wikipedia: How can user scripts
be deployed from GitHub to Wikipedia, as users try to load from the script hosted on</em> Wikipedia? Yeah I know this might
sound silly but many times it involved primitive copy-pasting locally to update the Wikipedia page.</p>
This bot is still going through the community processes, but I'm hoping to deploy it soon :D</p>
Lingering ideas</h2>
Oh I love some of these ideas.</p>
Non-GNU Linux from Scratch</h3>
I've always wondered how you can make a Linux system from Scratch without using gcc or GNU libc. I used to love a lot of
these esoteric Linux software stuff. It's obviously possible: there are projects</a> that have
achieved this feat, but I have yet to see a nice tutorial on a step-by-step construction of this system, similar to the
legendary LFS book. I hope to write a blogpost when I find out about how myself.</p>
WASM based package managing</h3>
This is semi-related to the thing above. I've been using Nix for a long</em> time and both the language and the package
manager are driving me a bit crazy. It's so burdensome to start a new package and/or write your own configuration,
because there are so many different ways to achieve the same thing and there is no rigid way of how things get to be
structured.</p>
I want to fix that, and my Rusted brain wants me to make something in Rust. So I'm thinking of making package
descriptions from Rust files that will compile to WebAssembly, then get loaded by the package manager. I'm hoping to be
able to use some of the free time that I have at the moment to try something out, after I had done a complete LFS
walkthrough and understood the process.</p>
Rustfmt competitor</h3>
I really want a replace for rustfmt because I had a suboptimal experience when trying to improve the codebase. A lot of
things are locked behind rustfmt's stability guarantee which forbids breaking changes to formatted code and forces new
things behind an edition gate. I don't like it because I don't think the codebase is solid enough for such a stability
guarantee to work. More cleanups are necessary. I don't think Topiary</a> will be good
enough in a reasonable timeframe to compete with rustfmt (it might be a little too ambitious).</p>
More investigation needed.</p>
SPI stuff</h3>
On Wikipedia there's this process called Sock puppet investigations that investigates whether someone has used multiple
accounts to abuse. There are two things that I really want to work on, when I get time:</p>

CheckUsers have access to IP and additional data that helps determine whether two accounts are operated by the same
person. I want to improve the CheckUser interface because I think the current interface is not streamlined enough for
a smooth operation. This will start as a user script adding shortcuts, and I plan to gradually add more stuff to have
a more complete investigation experience.</li>
SPIs are really hard. Now that we have large language models, it might be really interesting to gather data from past
cases and see which ones have resulted in blocks being placed and which ones have been declined. There are of course
levels to that, for example sometimes it might result in CheckUser being run and sometimes it won't. Having data and
using models to analyze this might give people who work at SPI a lot of insight as to what makes good SPI cases good
(factoring in variables such as response times, what actions resulted from the report, basic data about the filer and
the users that have been filed against), and maybe it may also be useful to predict (for fun) the course of new SPI
cases as they come in.</li>
</ul>
Wrapping Up</h2>
I like writing and it is nice to document stuff that I'm doing. But I just do a lot of things and it is sometimes hard
to fully summarize. I hope after this long post I can pick up and do more regular devlogs next.</p>
Did you like this post? Let me know :D</p>

Acknowledgements</h2>

Thanks errs</a> for the encouragement to write this post, and oli</a> for commenting on initial drafts of the proposal and providing more thinking on Proposal 4 and 4.5.</li> </ul>

Wrapping Up</h2>
I like writing and it is nice to document stuff that I'm doing. But I just do a lot of things and it is sometimes hard to fully summarize. I hope after this long post I can pick up and do more regular devlogs next.</p>
Did you like this post? Let me know :D</p>

`Where are the other sections?</h3> I didn't have time so I'll end here. I do want to summarize the state of some personal projects that I have been working on for the past few years in a future devlog, but I also want to get this post done</em>, so maybe in the next one!</p>`

beef's blog

Const Trait Counterexamples

Devlog 002

My First Patch to Linux

Devlog 001

beef's blog

Const Trait Counterexamples

Save this for the future</h2> These are some features that are not</em> essential for const traits. Including them will unnecessarily enlarge the scope of the RFC. But it might still be useful to propose them later.</p>

Devlog 002

Wrapping Up</h2> I like writing and it is nice to document stuff that I'm doing. But I just do a lot of things and it is sometimes hard to fully summarize. I hope after this long post I can pick up and do more regular devlogs next.</p> Did you like this post? Let me know :D</p>

My First Patch to Linux

Devlog 001

Wrapping Up</h2>
I like writing and it is nice to document stuff that I'm doing. But I just do a lot of things and it is sometimes hard to fully summarize. I hope after this long post I can pick up and do more regular devlogs next.</p>
Did you like this post? Let me know :D</p>