Static extension methods in C# 4.0 - by Joan Venge

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 379978 Comments
Status Closed Workarounds
Type Suggestion Repros 1
Opened 11/4/2008 9:31:37 AM
Access Restriction Public


This feature really improves the readability and discoverability of the code as well as the logical structure of class members.

This might not be an issue for instance methods where it makes more sense to use the method on the instance.

But for classes like Math, there is no alternative. In these cases, it makes more sense to call the method from the class itself.



It's just what one expects logically instead of:





You could have custom static classes like MathHelper, but this doesn't blend nicely with the code as a whole.

The same arguments were presented for instance extension methods where people could use  custom static classes instead of calling their method directly on the instance, but the win point for this was that it improved readability which it really did. Same goes for static extension methods IMO.

Please consider this feature.

What do you guys think?
Sign in to post a comment.
Posted by George Birbilis on 6/6/2012 at 7:50 AM
here's my scenario, I want to create a DependencyPropety.Register that allows for value coercion in Silverlight, but in a way that keeps it WPF source-code compatible (that is without edits in the source code)

now you force me to write

public static readonly DependencyProperty ContentScaleProperty =
WPF_DependencyProperty.Register("ContentScale", typeof(double), typeof(ZoomAndPanControl),
     new FrameworkPropertyMetadata(1.0, ContentScale_PropertyChanged, ContentScale_Coerce));

instead of

public static readonly DependencyProperty ContentScaleProperty =
DependencyProperty.Register("ContentScale", typeof(double), typeof(ZoomAndPanControl),
     new FrameworkPropertyMetadata(1.0, ContentScale_PropertyChanged, ContentScale_Coerce));

in the source code (you see I managed to make the rest of the code to be spelled in Silverlight exactly as in WPF)


using System;
using System.Windows;

namespace WPFCompatibility

    public static class WPF_DependencyProperty

        public static DependencyProperty Register(string name, Type propertyType, Type ownerType, FrameworkPropertyMetadata typeMetadata)
            DependencyProperty dp = DependencyProperty.Register(name, propertyType, ownerType, typeMetadata);
            FrameworkPropertyMetadata.AssociatePropertyWithCoercionMethod(dp, typeMetadata.CoerceValueCallback);
            return dp;


Posted by George Birbilis on 6/6/2012 at 7:30 AM
together with extension constructors, static extension methods ("injecting" static methods) are features that would be very useful in making compatibility layers for the source-code level (where one e.g. makes WPF code compile in Silveright)
Posted by dpuza on 9/24/2010 at 7:13 AM
Please add this in .NET 5, for all of the reasons already mentioned. Please.
Posted by hcoverlambda on 11/30/2009 at 10:29 AM
Another use case is static factories. Oh how I've longed for the ability to add custom static factory methods to a 3rd party class. Ibasa mentions some important ones as well.

I remember a lot of people scoffed at extension methods with the same old rhetoric; "Why would you want to do that?? You can just do xyz instead. It only saves a couple of keystrokes and doesn't add a lot of value. Etc, etc". Well, we have extension methods and they provide a great deal of utility and if used properly can make code much more succinct and understandable. I believe that static extension methods will also provide great utility. Possibly in ways that you won't be able to foresee.

I do understand what your saying about the pipelining but that doesn't mean there aren't any other compelling use cases.
Posted by Ibasa on 11/11/2009 at 11:17 AM
Another few points to add to this. I currently have a couple of xExtension classes with only static methods in them (not extension methods)
ObjectExtensions, which has Swap<T>(ref a, ref b).
MathExtensions, which has float overloads for all the maths functions.
BufferExtensions, which has some methods similar to memcmp, memchr and memset.
BitConverterExtensions, which has int SingleToInt32Bits(float value) and float Int32BitsToSingle(int value).

All of these would be nicer if I could use static extension methods instead of Extension helper classes. Please consider putting this in.
Posted by Joan Venge on 7/6/2009 at 4:22 PM
Yeah MS, please do this.
Posted by Stoj on 6/17/2009 at 8:03 PM
Agreed. "Less is best" when it comes to reducing the number of helper classes by allowing extension methods on static classes.
Posted by Ibasa on 3/31/2009 at 4:10 PM
Is this likely to get into version 5? It would reduce the number of "Helper" classes.
Posted by Microsoft on 3/31/2009 at 2:37 PM
Thanks for your suggestion.

We have explored the notion of static extension methods. In general it seems to be much less useful than instance extension methods - in the latter case you turn the whole code flow around, which really helps pipelined (fluent, man) scenarios, whereas in the former you just get to call the method off of a different class.

There is one kind of "static method" which might be more useful as an extension method - operators. This is because, much like today's extension methods, the class that they get called on is not explicit in the call syntax, but gets figured out by the compiler. And with today's operators you can't add them to any type other than yourself and your immediate relatives.

We have these and other kinds of extension members on our list of potential future features, but we are not taking any more features for the upcoming release, so I'll resolve this as Won't Fix.

Thanks again,

Mads Torgersen, C# Language PM
Posted by Joan Venge on 1/29/2009 at 3:38 PM
Thanks Mike, well put.
Posted by hcoverlambda on 1/20/2009 at 8:16 PM
I totally agree, this should have been added when instance extension methods were added and for the same reasons.