Static extension methods and Project Roslyn

Question

It has been noted here (and quite rightly so) that extension methods in .NET are just syntactic sugar for static method calls on instance variables.

However in relation to this question, I am wondering why extension methods for static access were omitted from the language specification?

As well as being a .NET (C#) developer, I am also a JavaScript developer, and you can model the equivalent of static method extensions in JavaScript - Hence my reasoning for delving a little deeper into this argument. (I am well aware that .NET and JavaScript are two exceptionally different languages!)

Let's examine the syntax for an extension method and how it compiles:

public static string Hash(this string value)
{
    // some logic here...
}

string x = "Hello World";

x.Hash();

compiles to

public static string Hash(string value)
{
    // some logic here...
}

string x = "Hello World";

Hash(x);

If you try to create a variable for a static type

class MyClass
{
    Console c; // error!
}

You can't!

If you try to pass a static type as a method parameter

public void DoThis(Console c) // error!
{
}

You can't!

So this defines the limitation of the language specification however in terms of an extension method, I can see the implementation being something along these lines...

public static void WriteLineInGreen(static Console c, string formatString, params object[] args)
{
    c.ForeGround = ConsoleColor.Green;
    c.WriteLine(formatString, args);
}

Console.WriteLineInGreen("Hello World {0}, {1}, {2}", ":-)", 1234, true);

Okay, it's not possible...why am I STILL asking? Answer..."Project Roslyn". Do you think this is something we might see along with all of the other language specification changes that will be implemented in Project Roslyn?

EDIT Anyone with any interest in Roslyn language extensions should watch this: https://channel9.msdn.com/Events/Build/2014/2-577

This question appears to be off-topic because it is about predicting future. — svick, Apr 19 '14 at 17:52
You seem to be looking for a discussion about Roslyn. I think that [the Roslyn discussion forum](https://roslyn.codeplex.com/discussions) is the right place for that, not SO. — svick, Apr 19 '14 at 17:58
Generally "Why doesn't language X implement feature Y?" are not good questions. Extension methods were added in C# 3. Eric Lippert has [commented](http://blogs.msdn.com/b/ericlippert/archive/2009/10/05/why-no-extension-properties.aspx) that the C# team had a huge amount of work to do for that release and everything not need for LINQ was cut. As for C# 6, static extension methods are not on the list of [proposed features](http://roslyn.codeplex.com/wikipage?title=Language%20Feature%20Status&referringTitle=Documentation). — Mike Zboray, Apr 19 '14 at 18:01
Actually, Eric has already answered a question on [this feature](http://stackoverflow.com/questions/4909156/why-arent-c-sharp-static-class-extension-methods-supported). — Mike Zboray, Apr 19 '14 at 18:09
To answer your question directly: "Q: I am wondering why extension methods for static access were omitted from the language specification?"... the answer is that there is no reason. We don't start out assuming we'll add every language extension that anyone can think of and then think of reasons to exclude them. We instead decide deliberately what features to include and we have reasons for including them. The one you suggest isn't among those we've decided to include. — Neal Gafter, Apr 20 '14 at 19:27

Olivier Jacot-Descombes · Accepted Answer · 2017-02-14T14:16:14.740

1

You cannot create an instance of a static type. var c = new Console(); does not work. Therefore, you cannot have an argument with a static type. In Console c, what would c be? The syntax of your proposed static type extension method would have to be something like this:

public static void WriteLineInGreen(static Console, string formatString,
                                    params object[] args)
{
    Console.ForeGround = ConsoleColor.Green;
    Console.WriteLine(formatString, args);
}

I think that the language specification changes related to Roslyn are due to the fact that language specification inconsistencies and inaccuracies have been found while working on Roslyn. It seems not very plausible to me that any new C# language features are related to Roslyn.

Update: Well, I was wrong on this last point. As @svick points out in his comment, the much better structure of the new compiler makes it easier to implement language changes.

Another important reason is that the language and compiler development has become open source. Microsoft invites the community to participate. (See: C# 7 Work List of Features.)

edited Feb 14 '17 at 14:16

answered Apr 19 '14 at 17:15

Olivier Jacot-Descombes

104,806
13
138
188

Have you seen this? https://channel9.msdn.com/Events/Build/2014/2-577 - Based on what I've seen here, in my opinion, Roslyn will extend the language beyond "inconsistencies" – Matthew Layton Apr 19 '14 at 17:47
2

“It seems not very plausible to me that any new C# language features are related to Roslyn.” They are. Reportedly, in the old compiler, it was hard to make changes to the language. With the Roslyn compiler, it's much easier, which is why C# 6.0 is going to contain bunch of small changes (which weren't worth the effort previously). – svick Apr 19 '14 at 17:56
There have been a few cases between C# and VB.NET where the spec blocked what in hindsight should have just been valid code. Rather than go out of our way to reimplement the block, we just deleted the offending portion of the spec. – Jason Malinowski Apr 19 '14 at 18:35
After reading these comments I conclude that Roslyn serves as a catalyst for new language features and some features are due to dropping some superfluous contraints. – Olivier Jacot-Descombes Apr 19 '14 at 20:25

Static extension methods and Project Roslyn

1 Answers1