Why pattern based programming in C#

Question

Wondering why C# is moving towards more pattern based programming rather than conventional ways.

Ex. The foreach statement expects that the loop source to have a magic method called GetEnumerator which returns an object which has a few more magic methods like MoveNext and Current, but they don't mandate any specific interface? C# could have mandated that a class to be used in foreach should implement IEnumerable or IEnumerable<T> as it does for theusing statement in that it expects an object to be used in using statement to implement the IDisposable interface.

Also, I see a similar trend with async/await keywords as well....

Of course there must be a good reason for that, but it seems a little odd for me to understand the reason why does compiler/CLR requires "magic methods" rather than relying on interfaces.

Answer 1

foreach

I would say it's both about performance and compatibility

• If you had chosen foreach to use IEnumerable it would have made all generic collections iteration very slow for value-types T (because of boxing/unboxing).
• If you had chosen to use IEnumerable<T> iterating over ArrayList and all non-generic collections from early .NET version would have not been possible.

I think the design decision was good. When foreach was introduced (.NET 1.1) there was nothing about generics in .NET (they were introduced in .NET 2.0). Choosing IEnumerable as a source of foreach enumeration would make using it with generic collections poor or would require a radical change. I guess designers already knew that they were going to introduce generics not that long time later.

Additionaly, declaring it as use IEnumerable<T> when it's available or IEnumerable when it's not is not much different then use available GetEnumerator method or do not compile when it's not available, is it?

update

As @mikez mentioned in comments, there is one more advantage. When you don't expect GetEnumerator to return IEnumerator/IEnumerator<T> you can return struct and don't worry about boxing when the enumerator is used by loop.

LINQ

The same magic methods situation occurs when you use LINQ and syntax based queries. When you write

var results = from item in source
              where item != "test"
              select item.ToLower();

it's transformed by compiler into

var results = source.Where(x => x != "test")
                    .Select(x => x.ToLower());

And because that code would work no matter what interface source implement the same applies to syntax-based query. As long as after transforming it to method-based query every method call can be properly assigned by compiler everything is OK.

async/await

I'm not that sure but think the same thing applies to async/await. When you use these keywords compiler generates a bunch of code for yourself, which is then compiled as if you'd written the code by yourself. And as long as code made by that transformation can be compiled everything is OK.