Sakib's blogA digital diary of programming, literature, films, and whatever else.Zola2026-05-25T00:00:00+00:00https://selectiveduplicate.github.io/blog/atom.xmlSolving tool bloat in Agentic AI at the gateway layer2026-05-25T00:00:00+00:002026-05-25T00:00:00+00:00
Abu Sakib
https://selectiveduplicate.github.io/blog/solving-tool-bloat-in-agentic-ai-at-the-gateway-layer/<p>Large tool catalogs, although valuable, mean every request is more expensive, slower, and more likely to produce the wrong result, since each request contains all the tools there are. Every tool definition consumes tokens, irrespective of the query needing that tool or not.</p>
<h2 id="on-the-tool-bloat-problem">On the tool bloat problem</h2>
<p>Tool bloat affects an AI application on three fronts: cost, response quality, and latency.</p>
<h3 id="cost">Cost</h3>
<p>Each tool definition in an API request consumes input tokens. A name, a description, and a parameter schema together typically run between 50 and 150 tokens, depending on how detailed the schema is. So an application with, say, 60 tools, may therefore append anywhere from 3,000 to 9,000 tokens to every request, before the user's actual message appears in the payload.</p>
<p>The expense recurs on every call. These tokens lack any informational value relative to the user's intent, which you pay for regardless. At higher throughput, the overhead figure scales linearly. Input token cost is a function of payload size, and tool definitions <em>are</em> payload.</p>
<p>The problem compounds in heterogeneous tools. An application might integrate calendar management, email, database querying, code execution, and document retrieval into a single API surface. To say that the application has many tools would be a misperception; rather, it has tools that are almost never all relevant to any single query. For example, if you want to schedule a meeting, you neither need the code execution tools in that request nor the database query tools. Yet all of them appear in the request, and thereby billed.</p>
<h3 id="quality">Quality</h3>
<p>Cost aside, sending irrelevant tools to an LLM actively degrades its ability to designate the right one. A May 2025 paper, <a rel="external" href="https://arxiv.org/abs/2505.03275">RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation</a>, measured tool-selection accuracy across varying tool pool sizes. It found that naive tool delivery, such as passing all available tools, produced a baseline accuracy of 13.62%. A retrieval-augmented approach that pre-filtered tools by semantic relevance raised that figure to 43.13%, more than tripling accuracy, while cutting prompt token usage by over 50%.</p>
<p>The mechanism behind this degradation is attention dilution. Transformer-based models allocate attention across all tokens in the context window. For a tool list long and mostly irrelevant, the model's attention distributes across entries that bear no relationship to the query. This increases the probability of selecting a tool that is plausible but wrong, one whose description overlaps superficially with the user's intent. It also exacerbates the risk of hallucinated parameter construction for tools the model has misidentified as applicable. Neither failure is easily caught without downstream validation. And both undermine the reliability of the system in ways that are, without careful instrumentation, difficult to attribute.</p>
<p>The issue becomes more concerning with tool descriptions that share vocabulary. For example, two tools may both respond to queries involving search, and an overloaded context makes the distinction harder for the model to maintain with accuracy.</p>
<h3 id="latency">Latency</h3>
<p>Larger inputs take longer to process. Take note of the fact that the model must attend to every token before generating output. So time-to-first-token—the interval between dispatching a request and receiving the start of a response—scales with input size. For interactive applications where a user waits for a response, this delay is user-visible. Excess tokens in the tool list contribute directly to it.</p>
<p>The latency effect is less acute than the cost or quality effects at moderate tool counts. It becomes significant, however, in high-volume, latency-sensitive environments, like real-time copilots, or systems where multiple LLM calls constitute a single user interaction. In those contexts, every nonessential token in the input is a compounding liability.</p>
<p>We can observe a common origin in these problems: a static tools array, while user intent remains specific. No query in a multi-domain agentic application requires access to every tool the application exposes. How to determine, per request and at runtime, the relevant tools, is the problem I will try to address in this post.</p>
<h2 id="the-naive-solutions-and-why-they-don-t-scale">The naive solutions and why they don't scale</h2>
<p>So how to tackle these complications? The usual approaches, although natural and addressing the issues in some measure, don't resolve the elementary problem, nor do they scale.</p>
<h3 id="curating-tools-per-endpoint">Curating tools per-endpoint</h3>
<p>Instinctively, you may want to curate the tools array manually: define which tools each endpoint receives and exclude everything else. It's a sound strategy for narrow, well-defined endpoints with stable, predictable intent.</p>
<p>But what about an endpoint that serves varied intent, the architecture that agentic applications veer toward? In the cases of, for example, a general-purpose assistant or conversational interface, the tools any given query might require alters with the query itself. Manual curation therefore, in that context, is not as much a configuration decision you make once as it is a system upkeep. For every new tool now requires a review of every endpoint's curated list. Each modification to application behavior carries with it risks of discrepancies between what the endpoint receives and the query's actual requirements.</p>
<p>We also observe a subtler failure where, by severely constraining an endpoint's tools, you unobtrusively debase capability. A tool mistakenly selected might result in a visible error, whereas a missing tool produces a response that simply does not invoke it, the latter being considerably harder to detect and diagnose.</p>
<h3 id="application-level-filtering">Application-level filtering</h3>
<p>In a more dynamic approach, the application discharges the filtering at runtime. Before assembling the request, the application inspects the query, ascertains relevance, and duly constructs the tools array.</p>
<p>However, every team building on the platform must implement this logic individually, with no shared standard for determining relevance. As a result, you have a patchwork of implementations, each maintained separately and susceptible to drift.</p>
<p>Application-level filtering also conjoins tool selection strategy with business logic. At one point, and recurringly, the filtering approach needs to change, because, for example, the tool catalog has grown or relevance thresholds require calibration. Now you must coordinate that change across every service that has implemented its own version. The affiliated cost will be prohibitive if your platform serves many API consumers.</p>
<h3 id="sending-everything">Sending everything</h3>
<p>The default, and by far the most common strategy, is to dispatch the full tools array on every request. It suffices for small tool sets, requiring no additional engineering, maintenance, or coordination.</p>
<p>Its inadequacy at scale, however, follows from the previous section. Moreover, there is an additional liability in that applications that default to sending everything implicitly treat tool selection as the model's problem. Reliability remains stable for a few tools, but degrades as the number of tools increases. The application, to make matters worse, lacks a method to detect this. Erroneous tool invocations and degraded response quality appear as downstream symptoms, often misattributed to other determinants.</p>
<h2 id="tool-selection-as-retrieval">Tool selection as retrieval</h2>
<p>Relevance is a relationship between a tool and a query, one that only materializes at runtime. So if relevance is a relationship between two pieces of text, we can express it as a geometric relationship between vectors. A text embedding model converts a string into a high-dimensional vector, where position in that space encodes meaning. Semantically related strings produce vectors that point in similar directions, and the cosine of the angle between them (cosine similarity) yields a value between -1 and 1 that quantifies that alignment.</p>
<p>So to apply this to tool selection, a practical set of steps would be as follows:</p>
<ul>
<li>Embed the user's query.</li>
<li>Embed each tool as a concatenation of its name and description.</li>
<li>Compute cosine similarity between the query vector and each tool vector, and pass only the highest-scoring tools to the model.</li>
</ul>
<p>Thus, not unlike RAG systems, semantic tool filtering retrieves only the tools the query actually needs, provided accurate, descriptive tool definitions.</p>
<h2 id="why-the-gateway-is-the-right-place-to-solve-this">Why the gateway is the right place to solve this</h2>
<p>So where does this <em>semantic filtering</em> actually execute? It might do so in the application, as discussed, but that reintroduces the foregoing coupling and fragmentation problems.</p>
<p>The correct answer is the API gateway.</p>
<p>The gateway, located between the application and the LLM, can intercept the tools array, perform semantic filtering, rewrite the payload, and forward the optimal request to the model.</p>
<p>This placement confers three distinct advantages. First, you define the filtering logic once; it applies uniformly across every API on the platform, precluding individual reimplementations across teams, services, and endpoints. Second, it is transparent to the application. Third benefit is unified governance; platform engineers can enforce it as infrastructure policy, as opposed to reliance on individual teams for consistent implementation.</p>
<p>The WSO2 AI Gateway in the WSO2 API Platform implements this motif through the <a rel="external" href="https://wso2.com/api-platform/policy-hub/policies/semantic-tool-filtering">Semantic Tool Filtering policy, available through the WSO2 Policy Hub</a>. The policy intercepts any OpenAI-compatible request, applies vector-similarity filtering to the tools array, and rewrites the payload before it gets to the model, all of it in an orderly fashion within the gateway's request pipeline. You do not have to alter anything upstream or downstream.</p>
<h2 id="how-the-semantic-tool-filtering-policy-works">How the Semantic Tool Filtering policy works</h2>
<h3 id="step-1-extract-the-query">Step 1: Extract the query</h3>
<p>The policy reads the user's latest message from the request body using a configurable <code>JSONPath</code> expression. The default, <code>$.messages[-1].content</code>, targets the last message in an OpenAI-style payload; but you can configure that to accommodate any request schema. Alternatively, if not structured JSON but embedded in a text, the policy extracts the query from a <code><userq></code> tag.</p>
<h3 id="step-2-extract-tool-definitions">Step 2: Extract tool definitions</h3>
<p>A second <code>JSONPath</code> expression extracts the tools array. The policy accommodates three common schemas:</p>
<ul>
<li><code>$.tools</code> for a flat array</li>
<li><code>$.tools[*].function</code> for OpenAI and Mistral-style function wrappers where each tool is an object with a nested <code>function</code> field</li>
<li><code>$.tools[0].function_declarations</code> for Gemini-style payloads.</li>
</ul>
<p>For text-based payloads, the policy reads <code><toolname></code> and <code><tooldescription></code> tags from the request body and strips them from the forwarded payload afterward.</p>
<h3 id="step-3-generate-embeddings">Step 3: Generate embeddings</h3>
<p>The policy embeds the user query and each tool, represented as <code>"<name>: <description>"</code>, using a configured embedding provider, namely, OpenAI, Mistral, and Azure OpenAI. You can configure each of these in the gateway's <code>config.toml</code> with an endpoint, model name, and API key.</p>
<p>Tool embeddings are cached using an LRU cache keyed by a SHA-256 hash of the provider, model, and tool description. That means tool embeddings are computed once and reused across requests. Only the user query embedding is computed fresh on each call.</p>
<h3 id="step-4-score-and-filter">Step 4: Score and filter</h3>
<p>Cosine similarity scores the query vector against each tool vector. The policy then applies one of two selection modes:</p>
<table><thead><tr><th>Mode</th><th>Behavior</th><th>Usage</th></tr></thead><tbody>
<tr><td><strong><code>By rank</code></strong></td><td>Retains the top-K tools by score; the number of most relevant tools to include is configurable, the default being <code>5</code></td><td>When a predictable, bounded tool count matters: cost control, latency targets</td></tr>
<tr><td><strong><code>By threshold</code></strong></td><td>Retains all tools scoring at or above a similarity threshold between <code>0.0</code> and <code>1.0</code>, the default being <code>0.7</code></td><td>When tool count should adapt to query specificity; a precise query might return one tool but an ambiguous one several</td></tr>
</tbody></table>
<h3 id="step-5-rewrite-and-forward">Step 5: Rewrite and forward</h3>
<p>The original tools array is replaced in-place with the filtered subset. The amended request proceeds to the LLM. From the model's perspective, these were the only tools it was ever given.</p>
<h3 id="the-embedding-cache">The Embedding cache</h3>
<p>The process described above calls an external embedding service on every request, or it would, without the built-in LRU cache. The cache makes the policy viable at production throughput, so let's briefly discuss that.</p>
<p>We can make a simple observation: tool names and descriptions remain static between requests, unlike user queries. So tool embeddings are computed once and stored; subsequent requests for the same tool retrieve the cached vector. Only the query embedding—the variable part—is computed anew on each request. At steady state, the cost of an embedding call per request reduces to only the cost of embedding a single short query string.</p>
<p>Cache keys are computed as a SHA-256 hash of three components: the embedding provider, the model name, and the tool description. The policy binds the provider and model to the key to take into account vectors produced by different models; they occupy different semantic spaces and hence are incompatible. In case of a different embedding model, existing cache entries will not match the new key format and will not be served, precluding stale or incompatible vectors from contaminating the filtered results.</p>
<p>Eviction follows an LRU-like strategy across APIs and tools within each API. Upon reaching capacity, the least recently used entries are evicted first in the cache. And when caching a new batch of tools, the policy calculates available slots before writing and skips tools that would not fit. It thus avoids evictions of recently used entries to accommodate a large batch that may itself see little reuse.</p>
<h3 id="format-flexibility">Format flexibility</h3>
<p>The majority of LLM API interactions involve JSON payloads, but not all. So the policy offers another option for frameworks that embed tool definitions differently.</p>
<p>Some frameworks inject tool definitions directly into the text of a system or user message. The policy accommodates this through a text-tag format. Tool definitions are marked with <code><toolname></code> and <code><tooldescription></code> tags; the user query is marked with a <code><userq></code> tag—for example:</p>
<pre class="giallo" style="color: #F8F8F2; background-color: #272822;"><code data-lang="plain"><span class="giallo-l"><span><toolname>get_weather</toolname> </span></span>
<span class="giallo-l"><span><tooldescription>Get current weather and 7-day forecast for a location</tooldescription> </span></span>
<span class="giallo-l"><span><userq>I'm planning a corporate retreat in Denver next weekend</userq></span></span></code></pre>
<p>You use the boolean parameters <code>userQueryIsJson</code> and <code>toolsIsJson</code> to specify the extraction mode the policy applies to each component independently. This means the two components need not share a format. A request can carry the user query as a JSON field while embedding tool definitions in text tags, or vice versa. The <code>JSONPath</code> parameters remain active for whichever component uses JSON extraction; for text-based components, those paths point to the field containing the raw text from which the policy extracts the tags.</p>
<p>Thus the policy does not prescribe a payload structure but adapts to the format the application already produces.</p>
<h3 id="choosing-a-selection-mode">Choosing a selection mode</h3>
<p>How the policy behaves depends on the selection mode you opt for.</p>
<p>The primary benefit of <code>By Rank</code> is predictability. Token consumption for each request is bounded and thereby no room for surprises at high throughput.</p>
<p>However, rank is a relative measure. The top five tools can all score poorly against the query, because the query is ambiguous, the tool descriptions sparse, or the user's intent genuinely spans multiple domains. <code>By Rank</code> still dispatches five tools, including ones marginally relevant at best. The mode merely returns the best available options within the defined count.</p>
<p>In <code>By Threshold</code>, the tool count adapts to the query: a precise, well-scoped request may return a single tool; a broad or ambiguous one may return several. It means the forwarded context reflects the actual semantic proximity between the query and the tool catalog, as opposed to a fixed count that may over- or under-represent relevance.</p>
<p>The tradeoff is that you need to calibrate deliberately. A lenient threshold value offers little reduction from the unfiltered baseline. A higher value might drop tools that are legitimately applicable but described in vocabulary that diverges from the query's phrasing. The right value depends on the semantic density of the tool catalog, the consistency of its descriptions, and the variability of user query phrasing. Although <code>0.7</code> is a reasonable starting point, there is no default universal, and we suggest that production deployments perform empirical tuning against representative query samples.</p>
<h3 id="the-role-of-tool-descriptions">The role of tool descriptions</h3>
<p>Across both modes, filtering quality is contingent on description quality, a point I've made earlier. Cosine similarity measures the angular distance between two embedding vectors; but it cannot recompense for descriptions that fail to encode what a tool actually does. A sound description produces a precise vector that scores strongly against queries about the sought property or objective and weakly against everything else.</p>
<h2 id="wrapping-up">Wrapping up</h2>
<p>Tool bloat can discreetly become a principal concern as applications accumulate capabilities, and compounds across cost, quality, and latency simultaneously. By dint of addressing it at the gateway, you can dispense the fix universally without affecting application code.</p>
On Collecting Result Types in Rust2021-08-08T00:00:00+00:002021-08-08T00:00:00+00:00
Abu Sakib
https://selectiveduplicate.github.io/blog/collecting-result/<p>There's a good chance that today's topic being somewhat complex, I will end up explaining some stuff poorly. If it is and leaves something important off the discussion, I apologize beforehand. As someone new to Rust, I'm trying not to get too overwhelmed but at the same time squeezing out all the fun I'm able to. So I'm not exploring too deep for now so that I don't get lost in confusion. For readers who are also fairly new to Rust, I hope this post helps your understanding, maybe piques your interest too, without casting an ominous shadow of fear about the language.</p>
<h2 id="so-iterators">So... iterators...</h2>
<p>Iterators are awesome! They're really handy when you're looping over a sequence of data. Iterators play a huge role in Rust and chances are that even in a trivial Rust program that you've written, there are iterators.</p>
<p>Rust has only one trait that a type needs to implement so that it's possible to iterate over a sequence of data belonging to those types.</p>
<p>Meet the <a rel="external" href="https://doc.rust-lang.org/std/iter/trait.Iterator.html"><code>Iterator</code></a> trait:</p>
<pre class="giallo" style="color: #F8F8F2; background-color: #272822;"><code data-lang="rust"><span class="giallo-l"><span style="color: #F92672;">pub</span><span style="color: #66D9EF;font-style: italic;"> trait</span><span style="color: #A6E22E;"> Iterator</span><span> {</span></span>
<span class="giallo-l"><span style="color: #66D9EF;font-style: italic;"> type</span><span style="color: #A6E22E;"> Item</span><span>;</span></span>
<span class="giallo-l"><span style="color: #88846F;"> // Lots of methods below...</span></span>
<span class="giallo-l"><span>}</span></span></code></pre>
<p>It has a bunch of functionalities. We'll look at only one of these: <code>collect()</code>.</p>
<p>Let's look at the signature:</p>
<pre class="giallo" style="color: #F8F8F2; background-color: #272822;"><code data-lang="rust"><span class="giallo-l"><span style="color: #66D9EF;">fn</span><span style="color: #A6E22E;"> collect</span><span><</span><span style="color: #66D9EF;">B</span><span style="color: #F92672;">:</span><span style="color: #66D9EF;"> FromIterator</span><span><</span><span style="color: #FD971F;">Self</span><span style="color: #F92672;">::</span><span style="color: #66D9EF;">Item</span><span>>>(</span><span style="color: #FD971F;">self</span><span>)</span><span style="color: #F92672;"> -></span><span style="color: #66D9EF;"> B</span></span>
<span class="giallo-l"><span style="color: #F92672;">where</span></span>
<span class="giallo-l"><span style="color: #FD971F;"> Self</span><span style="color: #F92672;">:</span><span style="color: #66D9EF;"> Sized</span><span>,</span></span>
<span class="giallo-l"><span>{</span></span>
<span class="giallo-l"><span style="color: #66D9EF;"> FromIterator</span><span style="color: #F92672;">::</span><span style="color: #A6E22E;">from_iter</span><span>(</span><span style="color: #FD971F;">self</span><span>)</span></span>
<span class="giallo-l"><span>}</span></span></code></pre>
<p>The signature, using <a rel="external" href="https://doc.rust-lang.org/reference/trait-bounds.html">trait bounds</a>, tells us that this method works on any type <code>B</code> provided that it implements the <a rel="external" href="https://doc.rust-lang.org/std/iter/trait.FromIterator.html"><code>FromIterator</code> trait</a>. Under the hood, it calls the <code>from_iter</code> function of the <code>FromIterator</code>.</p>
<p>This trait only has one method:</p>
<pre class="giallo" style="color: #F8F8F2; background-color: #272822;"><code data-lang="rust"><span class="giallo-l"><span style="color: #F92672;">pub</span><span style="color: #66D9EF;font-style: italic;"> trait</span><span style="color: #A6E22E;"> FromIterator</span><span><</span><span style="color: #66D9EF;">A</span><span>> {</span></span>
<span class="giallo-l"><span style="color: #F92672;"> pub</span><span style="color: #66D9EF;"> fn</span><span style="color: #A6E22E;"> from_iter</span><span><</span><span style="color: #66D9EF;">T</span><span>>(iter</span><span style="color: #F92672;">:</span><span style="color: #66D9EF;"> T</span><span>)</span><span style="color: #F92672;"> -></span><span style="color: #FD971F;"> Self</span></span>
<span class="giallo-l"><span style="color: #F92672;"> where</span></span>
<span class="giallo-l"><span style="color: #66D9EF;"> T</span><span style="color: #F92672;">:</span><span style="color: #66D9EF;"> IntoIterator</span><span><</span><span style="color: #66D9EF;">Item</span><span style="color: #F92672;"> =</span><span style="color: #66D9EF;"> A</span><span>>;</span></span>
<span class="giallo-l"><span>}</span></span></code></pre>
<p>This method is widely used to "collect" data that we're iterating over into a collection. If you read between the lines, you'll understand that you can use it to convert one collection into another type of collection.</p>
<p>Take the f<a rel="external" href="https://doc.rust-lang.org/std/iter/trait.Iterator.html#examples-28">ollowing example from the docs</a> where it iterates over an array (a collection) and turns it into a vector (another type of collection):</p>
<pre class="giallo" style="color: #F8F8F2; background-color: #272822;"><code data-lang="rust"><span class="giallo-l"><span style="color: #66D9EF;font-style: italic;">let</span><span> a</span><span style="color: #F92672;"> =</span><span> [</span><span style="color: #AE81FF;">1</span><span>,</span><span style="color: #AE81FF;"> 2</span><span>,</span><span style="color: #AE81FF;"> 3</span><span>];</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span style="color: #66D9EF;font-style: italic;">let</span><span> doubled</span><span style="color: #F92672;">:</span><span style="color: #66D9EF;"> Vec</span><span><</span><span style="color: #66D9EF;">i32</span><span>></span><span style="color: #F92672;"> =</span><span> a</span><span style="color: #F92672;">.</span><span style="color: #A6E22E;">iter</span><span>()</span></span>
<span class="giallo-l"><span style="color: #F92672;"> .</span><span style="color: #A6E22E;">map</span><span>(</span><span style="color: #F92672;">|&</span><span>x</span><span style="color: #F92672;">|</span><span> x</span><span style="color: #F92672;"> *</span><span style="color: #AE81FF;"> 2</span><span>)</span></span>
<span class="giallo-l"><span style="color: #F92672;"> .</span><span style="color: #A6E22E;">collect</span><span>();</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span style="color: #A6E22E;">assert_eq!</span><span>(</span><span style="color: #A6E22E;">vec!</span><span>[</span><span style="color: #AE81FF;">2</span><span>,</span><span style="color: #AE81FF;"> 4</span><span>,</span><span style="color: #AE81FF;"> 6</span><span>], doubled);</span></span></code></pre><h2 id="collecting-results">Collecting <code>Result</code>s</h2>
<p>What about collections that are not your run-of-the-mill collections, like arrays and vectors? What about a vector of <a rel="external" href="https://doc.rust-lang.org/std/result/enum.Result.html"><code>Result</code> types</a>?</p>
<blockquote>
<p><code>collect()</code> can also create instances of types that are not typical collections. For example, a <code>String</code> can be built from chars, and an iterator of <code>Result<T, E></code> items can be collected into <code>Result<Collection<T>, E></code>...</p>
</blockquote>
<p>According to the docs, you can do that, because <code>Result</code> types implement the <code>FromIterator</code> trait.</p>
<h2 id="down-the-rabbit-hole">Down the rabbit hole...</h2>
<p>Now let's turn our eyes to the example that's at the heart of today's rant here:</p>
<pre class="giallo" style="color: #F8F8F2; background-color: #272822;"><code data-lang="rust"><span class="giallo-l"><span style="color: #66D9EF;font-style: italic;">let</span><span> results</span><span style="color: #F92672;"> =</span><span> [</span><span style="color: #A6E22E;">Ok</span><span>(</span><span style="color: #AE81FF;">1</span><span>),</span><span style="color: #A6E22E;"> Err</span><span>(</span><span style="color: #E6DB74;">"nope"</span><span>),</span><span style="color: #A6E22E;"> Ok</span><span>(</span><span style="color: #AE81FF;">3</span><span>),</span><span style="color: #A6E22E;"> Err</span><span>(</span><span style="color: #E6DB74;">"bad"</span><span>)];</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span style="color: #66D9EF;font-style: italic;">let</span><span> result</span><span style="color: #F92672;">:</span><span style="color: #66D9EF;"> Result</span><span><</span><span style="color: #66D9EF;">Vec</span><span><_>,</span><span style="color: #F92672;"> &</span><span style="color: #A6E22E;">str</span><span>></span><span style="color: #F92672;"> =</span><span> results</span><span style="color: #F92672;">.</span><span style="color: #A6E22E;">iter</span><span>()</span><span style="color: #F92672;">.</span><span style="color: #A6E22E;">cloned</span><span>()</span><span style="color: #F92672;">.</span><span style="color: #A6E22E;">collect</span><span>();</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span style="color: #88846F;">// gives us the first error</span></span>
<span class="giallo-l"><span style="color: #A6E22E;">assert_eq!</span><span>(</span><span style="color: #A6E22E;">Err</span><span>(</span><span style="color: #E6DB74;">"nope"</span><span>), result);</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span style="color: #66D9EF;font-style: italic;">let</span><span> results</span><span style="color: #F92672;"> =</span><span> [</span><span style="color: #A6E22E;">Ok</span><span>(</span><span style="color: #AE81FF;">1</span><span>),</span><span style="color: #A6E22E;"> Ok</span><span>(</span><span style="color: #AE81FF;">3</span><span>)];</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span style="color: #66D9EF;font-style: italic;">let</span><span> result</span><span style="color: #F92672;">:</span><span style="color: #66D9EF;"> Result</span><span><</span><span style="color: #66D9EF;">Vec</span><span><_>,</span><span style="color: #F92672;"> &</span><span style="color: #A6E22E;">str</span><span>></span><span style="color: #F92672;"> =</span><span> results</span><span style="color: #F92672;">.</span><span style="color: #A6E22E;">iter</span><span>()</span><span style="color: #F92672;">.</span><span style="color: #A6E22E;">cloned</span><span>()</span><span style="color: #F92672;">.</span><span style="color: #A6E22E;">collect</span><span>();</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span style="color: #88846F;">// gives us the list of answers</span></span>
<span class="giallo-l"><span style="color: #A6E22E;">assert_eq!</span><span>(</span><span style="color: #A6E22E;">Ok</span><span>(</span><span style="color: #A6E22E;">vec!</span><span>[</span><span style="color: #AE81FF;">1</span><span>,</span><span style="color: #AE81FF;"> 3</span><span>]), result);</span></span></code></pre>
<p>Here we have an array of <code>Result</code> types, containing both <code>Ok</code> and <code>Err</code> variants. Using <code>collect()</code>, we're <em>trying</em> to collect that into a <code>Result</code>...</p>
<p>Hmm, that feels.. awkward...</p>
<p>We're not collecting into a vector of <code>Result</code>s, but rather into a <code>Result</code> that has a <code>Vector</code> variant.</p>
<p>So what? It does implement <code>FromIterator</code>, so <code>collect()</code> should work. Period.</p>
<p>Let's take a step back and try to deduce from what we know so far:</p>
<ul>
<li><code>Result</code> is an enum. So a <code>Result</code> type can only have one variant at a time, either <code>Ok</code>, or <code>Err</code>.</li>
<li>So after the operation on line 2, the <code>result</code> variable <em>should</em> contain only one variant, either the <code>Vec</code> variant (like the second <code>result</code> variable in the example ) or the <code>&str</code> variant representing the <code>Err</code>.</li>
</ul>
<p>It does end up having only one variant in each case, (the <code>Ok</code> variant with the vector, and the <code>Err</code> variant with an <code>&str</code>), but how is it only yielding the first <code>Err</code> variant?</p>
<h3 id="searching-for-answers">Searching for answers</h3>
<p>The magic happens inside the <a rel="external" href="https://doc.rust-lang.org/std/result/enum.Result.html#impl-FromIterator%3CResult%3CA%2C%20E%3E%3E">implementation of <code>FromIterator</code> for <code>Result</code> types</a>.</p>
<p>As I said at the beginning, I'm not going to dive too deep into the mystery behind this magic because that'd be something out of my depth (it is... for now). But we can go pretty far at understanding what's happening under the hood.</p>
<p>Let's take a look at the relevant part of the source code of that implementation:</p>
<pre class="giallo" style="color: #F8F8F2; background-color: #272822;"><code data-lang="rust"><span class="giallo-l"><span style="color: #F92672;">impl</span><span><</span><span style="color: #66D9EF;">A</span><span>,</span><span style="color: #66D9EF;"> E</span><span>,</span><span style="color: #66D9EF;"> V</span><span style="color: #F92672;">:</span><span style="color: #66D9EF;"> FromIterator</span><span><</span><span style="color: #66D9EF;">A</span><span>>></span><span style="color: #66D9EF;"> FromIterator</span><span><</span><span style="color: #66D9EF;">Result</span><span><</span><span style="color: #66D9EF;">A</span><span>,</span><span style="color: #66D9EF;"> E</span><span>>></span><span style="color: #F92672;"> for</span><span style="color: #66D9EF;"> Result</span><span><</span><span style="color: #66D9EF;">V</span><span>,</span><span style="color: #66D9EF;"> E</span><span>> {</span></span>
<span class="giallo-l"><span style="color: #88846F;"> /// Takes each element in the `Iterator`: if it is an `Err`, no further</span></span>
<span class="giallo-l"><span style="color: #88846F;"> /// elements are taken, and the `Err` is returned. Should no `Err` occur, a</span></span>
<span class="giallo-l"><span style="color: #88846F;"> /// container with the values of each `Result` is returned.</span></span>
<span class="giallo-l"><span style="color: #66D9EF;"> fn</span><span style="color: #A6E22E;"> from_iter</span><span><</span><span style="color: #66D9EF;">I</span><span style="color: #F92672;">:</span><span style="color: #66D9EF;"> IntoIterator</span><span><</span><span style="color: #66D9EF;">Item</span><span style="color: #F92672;"> =</span><span style="color: #66D9EF;"> Result</span><span><</span><span style="color: #66D9EF;">A</span><span>,</span><span style="color: #66D9EF;"> E</span><span>>>>(iter</span><span style="color: #F92672;">:</span><span style="color: #66D9EF;"> I</span><span>)</span><span style="color: #F92672;"> -></span><span style="color: #66D9EF;"> Result</span><span><</span><span style="color: #66D9EF;">V</span><span>,</span><span style="color: #66D9EF;"> E</span><span>> {</span></span>
<span class="giallo-l"><span style="color: #66D9EF;"> iter</span><span style="color: #F92672;">::</span><span style="color: #A6E22E;">process_results</span><span>(iter</span><span style="color: #F92672;">.</span><span style="color: #A6E22E;">into_iter</span><span>(),</span><span style="color: #F92672;"> |</span><span>i</span><span style="color: #F92672;">|</span><span> i</span><span style="color: #F92672;">.</span><span style="color: #A6E22E;">collect</span><span>())</span></span>
<span class="giallo-l"><span> }</span></span>
<span class="giallo-l"><span>}</span></span></code></pre>
<p>The comments mention the behavior we've just observed in the previous example. At the first encounter of an <code>Err</code> variant, it returns that variant and stops collecting. Otherwise, it collects all the values into a container (collection) and returns that instead.</p>
<p>We already know that <code>FromIterator</code> has a single method that a type needs to define in order to implement the trait, and that's <code>from_iter</code>; every type that implements it does so in different ways.</p>
<p>For <code>Result</code>, we see that it calls another utility function called <code>process_results</code> that does the actual job. <code>process_results</code> is tailored to work on <code>Result</code> type values.</p>
<p>Let's try to break it down as much as we can. Only keep in mind for now that <em>we're iterating over <code>Result</code> types</em>.</p>
<ul>
<li>From the signature, the single argument in <code>from_iter</code> has to implement the <code>IntoIterator</code> trait. If you scroll back a bit, we called <code>cloned()</code> before calling <code>collect()</code> on the array. And the r<a rel="external" href="https://doc.rust-lang.org/std/iter/struct.Cloned.html#impl-IntoIterator">eturn value type of <code>cloned()</code> implements <code>IntoIterator</code></a>.
<ul>
<li><code>cloned()</code> creates a new iterator that clones (makes copies of) the underlying elements, i.e. the <code>Result</code> types. The clones aren't of type <code>&T</code> but type <code>T</code>.</li>
</ul>
</li>
<li><code>process_results</code> takes two arguments: a closure and an iterator. Since <code>cloned()</code> yields type <code>T</code>, <code>into_iter()</code> is used on <code>iter</code> so that it's possible to iterate over <code>T</code> types (refer to the <a rel="external" href="https://doc.rust-lang.org/std/iter/index.html#the-three-forms-of-iteration">docs on the <code>iter</code> module</a> if you're confused; it summarizes the types of iteration existing in Rust).</li>
</ul>
<h4 id="the-one-who-processes-results">The one who processes Results</h4>
<p>Here's the whole <a rel="external" href="https://github.com/rust-lang/rust/blob/6830052c7b87217886324129bffbe096e485d415/library/core/src/iter/adapters/mod.rs#L138-L147"><code>process_results</code> function</a>:</p>
<pre class="giallo" style="color: #F8F8F2; background-color: #272822;"><code data-lang="rust"><span class="giallo-l"><span style="color: #66D9EF;">fn</span><span style="color: #A6E22E;"> process_results</span><span><</span><span style="color: #66D9EF;">I</span><span>,</span><span style="color: #66D9EF;"> T</span><span>,</span><span style="color: #66D9EF;"> E</span><span>,</span><span style="color: #66D9EF;"> F</span><span>,</span><span style="color: #66D9EF;"> U</span><span>>(iter</span><span style="color: #F92672;">:</span><span style="color: #66D9EF;"> I</span><span>,</span><span style="color: #F92672;"> mut</span><span> f</span><span style="color: #F92672;">:</span><span style="color: #66D9EF;"> F</span><span>)</span><span style="color: #F92672;"> -></span><span style="color: #66D9EF;"> Result</span><span><</span><span style="color: #66D9EF;">U</span><span>,</span><span style="color: #66D9EF;"> E</span><span>></span></span>
<span class="giallo-l"><span style="color: #F92672;">where</span></span>
<span class="giallo-l"><span style="color: #66D9EF;"> I</span><span style="color: #F92672;">:</span><span style="color: #66D9EF;"> Iterator</span><span><</span><span style="color: #66D9EF;">Item</span><span style="color: #F92672;"> =</span><span style="color: #66D9EF;"> Result</span><span><</span><span style="color: #66D9EF;">T</span><span>,</span><span style="color: #66D9EF;"> E</span><span>>>,</span></span>
<span class="giallo-l"><span style="color: #F92672;"> for</span><span><'</span><span style="color: #A6E22E;">a</span><span>></span><span style="color: #66D9EF;"> F</span><span style="color: #F92672;">:</span><span style="color: #A6E22E;"> FnMut</span><span>(</span><span style="color: #66D9EF;">ResultShunt</span><span><'</span><span style="color: #A6E22E;">a</span><span>,</span><span style="color: #66D9EF;"> I</span><span>,</span><span style="color: #66D9EF;"> E</span><span>>)</span><span style="color: #F92672;"> -></span><span style="color: #66D9EF;"> U</span><span>,</span></span>
<span class="giallo-l"><span>{</span></span>
<span class="giallo-l"><span style="color: #66D9EF;font-style: italic;"> let</span><span style="color: #F92672;"> mut</span><span> error</span><span style="color: #F92672;"> =</span><span style="color: #A6E22E;"> Ok</span><span>(());</span></span>
<span class="giallo-l"><span style="color: #66D9EF;font-style: italic;"> let</span><span> shunt</span><span style="color: #F92672;"> =</span><span style="color: #66D9EF;"> ResultShunt</span><span> { iter, error</span><span style="color: #F92672;">: &mut</span><span> error };</span></span>
<span class="giallo-l"><span style="color: #66D9EF;font-style: italic;"> let</span><span> value</span><span style="color: #F92672;"> =</span><span style="color: #A6E22E;"> f</span><span>(shunt);</span></span>
<span class="giallo-l"><span> error</span><span style="color: #F92672;">.</span><span style="color: #A6E22E;">map</span><span>(</span><span style="color: #F92672;">|</span><span>()</span><span style="color: #F92672;">|</span><span> value)</span></span>
<span class="giallo-l"><span>}</span></span></code></pre>
<p>Looks like the closure works on a type called <code>ResultShunt</code>... what the heck is that?</p>
<h4 id="the-iterator-that-wraps-another-iterator">The iterator that wraps another iterator</h4>
<p><code>ResultShunt</code> is another iterator that wraps the first iterator <code>iter</code> passed to the function. <a rel="external" href="https://github.com/rust-lang/rust/blob/6830052c7b87217886324129bffbe096e485d415/library/core/src/iter/adapters/mod.rs#L130-L133">Here's how <code>ResultShunt</code> looks like</a>:</p>
<pre class="giallo" style="color: #F8F8F2; background-color: #272822;"><code data-lang="rust"><span class="giallo-l"><span style="color: #88846F;">/// An iterator adapter that produces output as long as the underlying</span></span>
<span class="giallo-l"><span style="color: #88846F;">/// iterator produces `Result::Ok` values.</span></span>
<span class="giallo-l"><span style="color: #88846F;">///</span></span>
<span class="giallo-l"><span style="color: #88846F;">/// If an error is encountered, the iterator stops and the error is</span></span>
<span class="giallo-l"><span style="color: #88846F;">/// stored.</span></span>
<span class="giallo-l"><span style="color: #66D9EF;font-style: italic;">struct</span><span style="color: #A6E22E;"> ResultShunt</span><span><'</span><span style="color: #A6E22E;">a</span><span>,</span><span style="color: #66D9EF;"> I</span><span>,</span><span style="color: #66D9EF;"> E</span><span>> {</span></span>
<span class="giallo-l"><span> iter</span><span style="color: #F92672;">:</span><span style="color: #66D9EF;"> I</span><span>,</span></span>
<span class="giallo-l"><span> error</span><span style="color: #F92672;">: &</span><span>'</span><span style="color: #A6E22E;">a</span><span style="color: #F92672;"> mut</span><span style="color: #66D9EF;"> Result</span><span><(),</span><span style="color: #66D9EF;"> E</span><span>>,</span></span>
<span class="giallo-l"><span>}</span></span></code></pre>
<p>At this point, let's think through a couple of things:</p>
<ul>
<li>The closure is iterating over <code>ResultShunt</code> types. That could only mean that <code>ResultShunt</code> type implements the <code>Iterator</code> trait.</li>
<li>The doc comments describe the behavior we're investigating.
<ul>
<li>Quite intuitively, the <code>error</code> field only cares about the <code>E</code> type of a <code>Result</code> since it has to stop at the first encounter of an <code>Err</code> variant.</li>
</ul>
</li>
</ul>
<p>The return type of <code>process_results</code> is a <code>Result<U,E></code> type, whereas the closure it takes as a parameter returns only the <code>Ok</code> value <code>U</code>.</p>
<p><em>That's how the <code>collect</code> method in the closure ends up collecting the <code>Ok</code> variants if there are no errors.</em></p>
<p>We don't need to go over all of <a rel="external" href="https://github.com/rust-lang/rust/blob/6830052c7b87217886324129bffbe096e485d415/library/core/src/iter/adapters/mod.rs#L149-L197">this implementation</a>. For now, notice the type parameters that show up in the <code>impl</code> signature:</p>
<pre class="giallo" style="color: #F8F8F2; background-color: #272822;"><code data-lang="rust"><span class="giallo-l"><span style="color: #F92672;">impl</span><span><</span><span style="color: #66D9EF;">I</span><span>,</span><span style="color: #66D9EF;"> T</span><span>,</span><span style="color: #66D9EF;"> E</span><span>></span><span style="color: #66D9EF;"> Iterator</span><span style="color: #F92672;"> for</span><span style="color: #66D9EF;"> ResultShunt</span><span><'</span><span style="color: #A6E22E;">_</span><span>,</span><span style="color: #66D9EF;"> I</span><span>,</span><span style="color: #66D9EF;"> E</span><span>></span></span>
<span class="giallo-l"><span style="color: #F92672;">where</span></span>
<span class="giallo-l"><span style="color: #66D9EF;"> I</span><span style="color: #F92672;">:</span><span style="color: #66D9EF;"> Iterator</span><span><</span><span style="color: #66D9EF;">Item</span><span style="color: #F92672;"> =</span><span style="color: #66D9EF;"> Result</span><span><</span><span style="color: #66D9EF;">T</span><span>,</span><span style="color: #66D9EF;"> E</span><span>>>,</span></span>
<span class="giallo-l"><span>{</span></span>
<span class="giallo-l"><span style="color: #66D9EF;font-style: italic;"> type</span><span style="color: #A6E22E;"> Item</span><span style="color: #F92672;"> =</span><span style="color: #66D9EF;"> T</span><span>;</span></span>
<span class="giallo-l"><span style="color: #F92672;">...</span></span></code></pre>
<p>Here <code>I</code> is the old iterator over <code>Result</code> types. But notice the associated type here:</p>
<pre class="giallo" style="color: #F8F8F2; background-color: #272822;"><code data-lang="rust"><span class="giallo-l"><span style="color: #F92672;">...</span></span>
<span class="giallo-l"><span style="color: #66D9EF;font-style: italic;">type</span><span style="color: #A6E22E;"> Item</span><span style="color: #F92672;"> =</span><span style="color: #66D9EF;"> T</span><span>;</span></span>
<span class="giallo-l"><span style="color: #F92672;">...</span></span></code></pre>
<p>This indicates the <em>type</em> of elements being iterated over. So <code>collect</code> is actually collecting this <code>T</code> type, which already has a <code>FromIterator</code> implementation (in our case, it's an integer). That explains how it yielded the vector containing all <code>Ok</code> variants in our example.</p>
<h4 id="finally-getting-there">Finally getting there...</h4>
<p>The implementation <a rel="external" href="https://github.com/rust-lang/rust/blob/6830052c7b87217886324129bffbe096e485d415/library/core/src/iter/adapters/mod.rs#L168-L183">has a try_fold method</a>. Again, only the following bit of code is relevant for now:</p>
<pre class="giallo" style="color: #F8F8F2; background-color: #272822;"><code data-lang="rust"><span class="giallo-l"><span style="color: #A6E22E;">Err</span><span>(e)</span><span style="color: #F92672;"> =></span><span> {</span></span>
<span class="giallo-l"><span style="color: #F92672;"> *</span><span>error</span><span style="color: #F92672;"> =</span><span style="color: #A6E22E;"> Err</span><span>(e);</span></span>
<span class="giallo-l"><span style="color: #66D9EF;"> ControlFlow</span><span style="color: #F92672;">::</span><span style="color: #A6E22E;">Break</span><span>(</span><span style="color: #F92672;">try</span><span> { acc })</span></span>
<span class="giallo-l"><span>}</span></span></code></pre>
<p>We can disregard the feeling of "understanding everything", which is impossible, in favor of how much we've been able to dig up incrementally and make a sense out of. And seeing the above bit of code will make a click sound in your brain...</p>
<ul>
<li>At the encounter of an <code>Err</code>, its value is stored in the <code>error</code> field of the <code>ResultShunt</code> type. Then it just stops iterating, as advertised.</li>
<li><code>process_results</code> makes a return with either success values or the error value (the last two lines):</li>
</ul>
<pre class="giallo" style="color: #F8F8F2; background-color: #272822;"><code data-lang="rust"><span class="giallo-l"><span style="color: #66D9EF;font-style: italic;">let</span><span> value</span><span style="color: #F92672;"> =</span><span style="color: #A6E22E;"> f</span><span>(shunt);</span></span>
<span class="giallo-l"><span>error</span><span style="color: #F92672;">.</span><span style="color: #A6E22E;">map</span><span>(</span><span style="color: #F92672;">|</span><span>()</span><span style="color: #F92672;">|</span><span> value)</span></span></code></pre>
<p>This is the last stretch of explanation that we need to wrap this up. Let's break it down:</p>
<ul>
<li>Remember the closure signature we observed earlier in <code>process_results</code>. It returns the <code>Ok</code> value. So the <code>value</code> above is just that (a string, integer whatever, but specifically in the example of ours it's an integer).</li>
<li>Next we're <code>map</code>ping over the <code>error</code> variable, which is a <code>Result</code> type. <a rel="external" href="https://doc.rust-lang.org/std/result/enum.Result.html#method.map">This is how <code>map</code> works on <code>Result</code> types</a>:
<ul>
<li>It doesn't touch the <code>Err</code> value, but applies the closure to the <code>Ok</code> value, transforming the initial <code>Result</code> into another. The closure argument is <a rel="external" href="https://doc.rust-lang.org/std/primitive.unit.html">the "unit" type</a>, meaning it's taking no argument and mapping the <code>Ok</code> values to <code>value</code>.</li>
</ul>
</li>
<li>Now if the program encountered an error, the <code>error</code> variable already contains it, and the <code>map</code> operation above wouldn't matter because it only touches the <code>Ok</code> values. That's how we get <code>Err("nope")</code> in the first case of our example.</li>
<li>Otherwise, <code>collect</code> collects the <code>Ok</code> values into a collection, and we're getting <code>Ok(vec![1, 3])</code> in the second case of our example.</li>
</ul>
<p>Phew! 😌 That was a wild ride but we've managed to solve much of the mystery! I'm going to scream with joy into my pillow and then pet my cat... 🎉🎉💪</p>
<h2 id="parting-words">Parting words</h2>
<p>Thanks for reading up to this point and descent into a bit of madness with me. Feel free to hit me up on <a rel="external" href="https://twitter.com/Slctvdplcate">Twitter</a> with any feedback that you might have. I hope you find it useful in some way.</p>
<p>This article could not have been possible without the following fine people and communities:</p>
<ul>
<li>The amazing community of <a rel="external" href="https://www.twitch.tv/togglebit/about">Togglebit</a> where I started the initial discussion around the topics.</li>
<li><a rel="external" href="https://github.com/shepmaster">Jake Goulding</a> for jumping in on the Rust Discord server so quickly and being patient with my questions.</li>
</ul>
Rust closures: How a closure can implement more than one trait2021-07-04T00:00:00+00:002021-07-04T00:00:00+00:00
Abu Sakib
https://selectiveduplicate.github.io/blog/closure-traits-rust/<p>A pretty interesting conversation took place on a <a rel="external" href="https://twitter.com/Slctvdplcate/status/1404843998297018370?s=20">series of Tweets</a> a while back on Rust closures. This was (and still is, although less than before) a confusing topic for me as a Rust newbie. So I was expecting some help from the Rust Twitter community. What I'm about to discuss today comes as a side effect out of that discussion; it wasn't my line of query initially.</p>
<p>My confusion centered around how closures implement the three traits <code>Fn</code>, <code>FnOnce</code>, and <code>FnMut</code>. From a slender look it looks fairly simple:</p>
<ul>
<li>You can call closures that implement <code>Fn</code> multiple times; you can't use them to mutate anything.</li>
<li><code>FnOnce</code> closures are callable only once. This is for scenarios where a piece of data could be <em>moved into</em> the closure.
So after the first call, you can't call that closure again since it's been moved during the first call (unless the data type in question implements the <code>Clone</code>
trait).</li>
<li>Closures that mutate the state implement <code>FnMut</code>. You can call this type of closure more than one time.</li>
</ul>
<p>Let's look at an example:</p>
<pre class="giallo" style="color: #F8F8F2; background-color: #272822;"><code data-lang="rust"><span class="giallo-l"><span style="color: #66D9EF;">fn</span><span style="color: #A6E22E;"> main</span><span>() {</span></span>
<span class="giallo-l"><span style="color: #88846F;"> // this closure doesn't capture anything </span></span>
<span class="giallo-l"><span style="color: #66D9EF;font-style: italic;"> let</span><span> print_</span><span style="color: #F92672;"> = |</span><span>film, rating</span><span style="color: #F92672;">|</span><span style="color: #A6E22E;"> println!</span><span>(</span><span style="color: #E6DB74;">"{}: {}"</span><span>, film, rating);</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span style="color: #66D9EF;font-style: italic;"> let</span><span> film_ratings</span><span style="color: #F92672;"> =</span><span> [(</span><span style="color: #E6DB74;">"Sunset Boulevard"</span><span>,</span><span style="color: #AE81FF;"> 7</span><span>), (</span><span style="color: #E6DB74;">"The Last"</span><span>,</span><span style="color: #AE81FF;"> 6</span><span>), (</span><span style="color: #E6DB74;">"Drive"</span><span>,</span><span style="color: #AE81FF;"> 8</span><span>)];</span></span>
<span class="giallo-l"><span> </span></span>
<span class="giallo-l"><span style="color: #F92672;"> for</span><span> (film, rating)</span><span style="color: #F92672;"> in</span><span> film_ratings</span><span style="color: #F92672;">.</span><span style="color: #A6E22E;">iter</span><span>() {</span></span>
<span class="giallo-l"><span style="color: #A6E22E;"> print_</span><span>(film, rating);</span></span>
<span class="giallo-l"><span> }</span></span>
<span class="giallo-l"><span>}</span></span></code></pre>
<p>The comment says it: this closure doesn't capture anything from the scope. So what trait does it implement?</p>
<p>Let's look at the <a rel="external" href="https://doc.rust-lang.org/std/ops/trait.Fn.html">docs on <code>Fn</code></a>:</p>
<blockquote>
<p>Fn is implemented automatically by closures which only take immutable references to captured variables or don't capture anything at all...</p>
</blockquote>
<p>So that's it then, right?</p>
<p>Hmm, I have trust issues so let's test that statement on our piece of code. <a rel="external" href="https://twitter.com/oconnor663">Jack</a> was kind enough to provide the following code snippet that checks what trait(s) the closure implements.</p>
<p>It uses <a rel="external" href="https://doc.rust-lang.org/reference/types/trait-object.html"><em>trait objects</em></a> to create three variables of three types corresponding to each of the traits <code>Fn</code>, <code>FnOnce</code> and <code>FnMut</code>. Then they're assigned to the closure.</p>
<pre class="giallo" style="color: #F8F8F2; background-color: #272822;"><code data-lang="rust"><span class="giallo-l"><span style="color: #66D9EF;">fn</span><span style="color: #A6E22E;"> main</span><span>() {</span></span>
<span class="giallo-l"><span style="color: #66D9EF;font-style: italic;"> let</span><span> print_</span><span style="color: #F92672;"> = |</span><span>film, rating</span><span style="color: #F92672;">|</span><span style="color: #A6E22E;"> println!</span><span>(</span><span style="color: #E6DB74;">"{}: {}"</span><span>, film, rating);</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span style="color: #66D9EF;font-style: italic;"> let</span><span> film_ratings</span><span style="color: #F92672;"> =</span><span> [(</span><span style="color: #E6DB74;">"Sunset Boulevard"</span><span>,</span><span style="color: #AE81FF;"> 7</span><span>), (</span><span style="color: #E6DB74;">"The Last"</span><span>,</span><span style="color: #AE81FF;"> 6</span><span>), (</span><span style="color: #E6DB74;">"Drive"</span><span>,</span><span style="color: #AE81FF;"> 8</span><span>)];</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span style="color: #F92672;"> for</span><span> (film, rating)</span><span style="color: #F92672;"> in</span><span> film_ratings</span><span style="color: #F92672;">.</span><span style="color: #A6E22E;">iter</span><span>() {</span></span>
<span class="giallo-l"><span style="color: #A6E22E;"> print_</span><span>(film, rating);</span></span>
<span class="giallo-l"><span> }</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span style="color: #66D9EF;font-style: italic;"> let</span><span> _this_works</span><span style="color: #F92672;">: &dyn</span><span style="color: #A6E22E;"> FnOnce</span><span>(_, _)</span><span style="color: #F92672;"> = &</span><span>print_;</span></span>
<span class="giallo-l"><span style="color: #66D9EF;font-style: italic;"> let</span><span> _this_works_too</span><span style="color: #F92672;">: &dyn</span><span style="color: #A6E22E;"> FnMut</span><span>(_, _)</span><span style="color: #F92672;"> = &</span><span>print_;</span></span>
<span class="giallo-l"><span style="color: #66D9EF;font-style: italic;"> let</span><span> _all_of_these_work</span><span style="color: #F92672;">: &dyn</span><span style="color: #A6E22E;"> Fn</span><span>(_, _)</span><span style="color: #F92672;"> = &</span><span>print_;</span></span>
<span class="giallo-l"><span>}</span></span></code></pre>
<p>This code compiles without so much as a warning...</p>
<p>So... the closure implements each trait. The question that arises now is why it ends up implementing all three (put pressure on the phrase "ends up").</p>
<p>I found a <a rel="external" href="https://stackoverflow.com/questions/30177395/when-does-a-closure-implement-fn-fnmut-and-fnonce#30232500">Stack Overflow</a> answer that started shedding some light on that question.</p>
<p>It says that all closures implement <code>FnOnce</code>. Why? Because you should be able to call a closure at least once. Closures are functions, and if you can't call a function at least once it's not living up to its name is it?!</p>
<p>So our closure implements <code>FnOnce</code>. And according to the docs, since it doesn't capture anything, it also implements <code>Fn</code>. That's two out of three. What about the third one <code>FnMut</code>?</p>
<p>The following line <a rel="external" href="https://doc.rust-lang.org/std/ops/trait.Fn.html">in the <code>Fn</code> docs</a> tries to give something away:</p>
<blockquote>
<p>Since both FnMut and FnOnce are supertraits of Fn, any instance of Fn can be used as a parameter where a FnMut or FnOnce is expected.</p>
</blockquote>
<p>Wait what? "Supertraits"?</p>
<p>Supertraits are Rust's way of achieving inheritance-like features. You can define a trait that uses some of the functionalities of another trait. The first trait then becomes the "supertrait" (or "parent trait", somewhat mirroring the OOP term "parent class"), and the second trait that depends on the first one becomes a "subtrait".</p>
<p>For a type that implements a subtrait, it also needs to implement its supertrait. That's enough, for now, to understand what's going on with our closures. I might delve into supertraits in another article in the future for my sanity (and clarity on it).</p>
<p>In our closure's case, so another way to explain its behavior is that since it implements <code>Fn</code>, it also implements the supertraits <code>FnOnce</code> and <code>FnMut</code>. This marks another claim made in that Stack Overflow answer:</p>
<blockquote>
<p>A closure |...| ... will automatically implement as many of those [traits] as it can.</p>
</blockquote>
<p>Bottomline:</p>
<ul>
<li>All closures implement <code>FnOnce</code>. This has to happen since all closures can at least be called once.</li>
<li>Our example closure doesn't capture anything from its sorrounding scope. Because of that, it implements <code>Fn</code>.</li>
<li>In order to implement <code>Fn</code>, it also ends up implementing the spuertraits <code>FnOnce</code> and <code>FnMut</code>.</li>
</ul>
<p>Oh <code>FnOnce</code> is also a supertrait of <code>Fnmut</code>...</p>
<p>That's it for today's ramblings. Hope you've found it useful in some way. Thanks for reading!</p>