IEnumerable<T> in C#: How foreach Really Works

IEnumerable<T> is the one promise every collection makes: "hand me a way to visit your items, one at a time." foreach is just a polite way of asking for it.

You've now written foreach dozens of times in this module — over arrays, lists, dictionaries, sets, even stacks and queues. It always just works, no matter which collection you point it at. In the previous lesson, you learned why: every one of those types implements IEnumerable<T>. This lesson stops at the surface of that idea and asks: what is IEnumerable<T>, actually, and what does foreach do with it?

This is a gentle first look, not a deep dive — the full mechanics of custom iterators (the yield keyword) and LINQ, which is built entirely on top of IEnumerable<T>, come later in this course. Here, the goal is just a solid, correct mental model of what "enumerable" means and how foreach actually uses it.

What Is It?

The Simple Explanation

Something is enumerable if you can visit each of its items, one after another, in order. IEnumerable<T> is C#'s way of saying "I promise you can do that to me." It doesn't promise a Count. It doesn't promise indexing. It promises exactly one thing: you can walk through my items.

The Technical Definition

IEnumerable<T> is a generic interface with exactly one member:

That's the entire contract. A type is enumerable simply by promising it can produce an enumerator — a separate, small helper object whose entire job is to remember "where am I in this walk-through, and what's the current item?" IEnumerator<T>, the thing GetEnumerator() returns, has its own small contract:

Why Does It Exist?

The Problem

Without a shared contract, every collection type would need its own bespoke way of being looped over — an array would need one kind of loop syntax, a dictionary a different one, a custom collection type you write yourself yet another. Code that wants to "just visit every item" would need a separate code path for every single collection type it might ever encounter, including ones that don't exist yet.

The Solution

IEnumerable<T> gives every collection type — built into .NET, or written by you — one shared, standard way to expose "walk through my items." Once a type implements it, it automatically gets to plug into foreach, and (later in this course) the entire LINQ query system, without either of those needing to know anything specific about how that type stores its data internally.

Big Picture

foreach (string name in names)
    Console.WriteLine(name);

IEnumerator<string> enumerator = names.GetEnumerator();
try
{
    while (enumerator.MoveNext())
    {
        string name = enumerator.Current;
        Console.WriteLine(name);
    }
}
finally
{
    enumerator.Dispose();
}

How It Works

Simple Example

Let's build a tiny custom collection from scratch, and make it work with foreach by implementing IEnumerable<T> ourselves — no shortcuts, so you can see exactly how the pieces fit together.

Code → Meaning → Result:

• NameList doesn't do the walking itself — it just knows how to produce a fresh NameEnumerator whenever asked, via GetEnumerator().
• NameEnumerator is the one that actually remembers position: it starts at -1 (before the first item), and each MoveNext() call steps forward by one, reporting false once it runs off the end.
• The moment NameList implements IEnumerable<string>, it can be used in a foreach exactly like an array or a List<T> — no special casing anywhere in the language.

Real-World Example

A team builds a small WeeklySchedule class for a shift-planning app — it wraps a fixed 7-day array internally, but the team wants callers to be able to simply foreach over "today's shifts for the week" without knowing or caring that an array is involved underneath.

Notice this version doesn't need a hand-written enumerator class at all — since _shifts is a List<Shift>, and List<T> is already enumerable, WeeklySchedule can simply delegate to it. This is by far the most common way real code implements IEnumerable<T>: wrap an already-enumerable collection internally, and forward the request.

Analogy

Under the Hood

Common Confusion

1. IEnumerable<T> vs IEnumerator<T> — easy to mix up by name

They sound almost identical, but they answer different questions. IEnumerable<T> asks "can I be walked through?" — a collection implements this. IEnumerator<T> asks "where are we right now in that walk-through?" — the enumerator returned by GetEnumerator() implements this. You almost never implement IEnumerator<T> directly in everyday code (as the real-world example showed, delegating to an already-enumerable field is far more common) — but understanding what it does makes foreach far less mysterious.

2. "Enumerable" doesn't mean "has a Count" or "can be indexed"

As you learned in the Collection Interfaces lesson, IEnumerable<T> is the smallest, most basic contract in the whole hierarchy. Being enumerable only promises sequential access — nothing about size, position, or mutability. Don't assume every IEnumerable<T> you receive has a Count or supports indexing; if you need those, the parameter type should say so explicitly (ICollection<T> or IList<T>).

Common Mistakes

Mistake 1 — Assuming every IEnumerable<T> has a Length or Count

Wrong — this won't compile; IEnumerable<T> makes no such promise:

Correct — if a count is genuinely needed, require a more specific interface:

Mistake 2 — Building a custom enumerator that shares one position field on the collection itself

Storing "current position" directly on the collection class (instead of a separate enumerator, as shown in the Simple Example above) means two simultaneous foreach loops over the same instance would corrupt each other's progress. Always give each walk-through its own independent enumerator object, exactly as GetEnumerator() is meant to do.

Mistake 3 — Modifying a collection while a foreach loop is enumerating it

You saw this exact mistake in the List<T> lesson — it throws InvalidOperationException. Now you know why: most built-in enumerators detect a change to the underlying collection mid-walk-through and deliberately fail loudly, rather than silently producing incorrect or skipped results. Collect items to remove first, or loop by index backwards, as shown in that earlier lesson.

When Should I Use It?

Mental Model

Key Takeaway

Check Your Understanding

You've taken a first look at how IEnumerable<T> and foreach connect. Let's check your understanding.

You've completed Part IV — Collections and Data. You now understand arrays, multidimensional and jagged arrays, List<T>, Dictionary<TKey,TValue>, HashSet<T>, Stack<T> and Queue<T>, the interface hierarchy that ties them together, and the first-look mechanics of IEnumerable<T> that make foreach — and eventually LINQ — possible.